Libraries are not found #2082
Comments
|
Ok I will close this as this doesn't happen anymore with latest git, despite from that working on Windows with the Gazebo GUI would be great, I hope this will get fixed soon. |
|
Hello @AreaScout, what error do you have in running |
|
@traversaro Ok I have to reopen this, again I have troubles with the library not found error message, Importer.dlload fails every time inside gz script, no matter what path I add to it, even if I directly copy the dll to the location gz starts, it does not dlopen it, what could that be? On my PC in my company this does not happen but that environment is screwed up with an unresolvable package conflict. I still got this and if I start simple_demo_qml.exe a window opens and closes immediately with this console output: 
But all files claimed to be not in that folder or the folder does not exist are there! Please help |
|
How did you installed gz-sim ? Can you report the output of |
|
Also, it would be useful to know how the |
|
I didn't install it, I build the whole project from source Regards, |
|
Apparently your conda environment gz-test has a mixture of conda-forge and anaconda/defaults packages, that is not a supported workflow (see https://conda-forge.org/docs/user/tipsandtricks.html#why-does-that-happen). Which command did you use to create that environment? A possible solution is to create a new environment passing also the -c nodefaults option to make sure that the defaults channel is not used. |
|
Well some packages needed I only found from anaconda packages, but that was not much or even wrong, but I don't think that this is the reason I have this path problems, what else could that cause ? |
|
I just followed this instructions |
I am not sure if the problem are independent. Anyhow, probably you can debug the loading problems by installing https://github.com/lucasg/Dependencies, launching it in the environment, load the dll that is causing loading problems and check if more information are printed. |
Good point, I will double check, but probably -c nodefaults should be added there as well, probably it went unnoticed as most gz users actually use miniforge or mambaforge . |
|
Well I did a new environment and even with the -c nodefaults switch it added non conda-forge packages |
That is quite strange. Can you provide exactly the commands you use to create this environment? From the docs in https://gazebosim.org/docs/garden/install_windows_src it seems that the commands should be: However, the fact that in your environemnts |
|
pybind11 is installed, ogre and ogre-next as well for the envs\gz-test, for the new one envs\gz-bin I didn't install ogre because I only wanted to test if all packages got installed from conda-forge channel and by the way pybind11 is installed on both environments gz-test and gz-bin Regards, Daniel |
|
Right, I missed the pybind11, sorry about that . Can you share the commands you used to create the env? I tried with a miniconda install and the instructions from the tutorial and in my case all the packages got installed from conda-forge. |
|
Sure, I reinstalled the environment, here are my commands! Regards, |
|
Sorry, did you tried specifying |
For me not, that doesn't bring us forward, the error Libraries are not found still exist and I don't think that packages only from conda-forge channel will fix it, or do you thing it is purposed to do so? Regards, |
The error message seems that Anyhow, if you want to debug directly the causes of the problem in loading the dll, you can use Dependencies as mentioned in #2082 (comment) . |
|
Ah! sorry didn't report that back, yes I did check already and all dependencies are there, here is the output And the output from the tool you mentioned -> |
Of course, I did it several times now and the outcome was always the same |
Can you try to also add |
|
Still the same: |
|
Sorry, I am out of ideas on why this is happening. Probably you can try to create the environment in one shot or similar, in general anyhow mixing defaults and conda-forge can lead to ABI and other linking problems such as the one you are experiencing here. |
|
I will do some more tests, It could also be the way that search path is generated by cmake maybe there is some clash with some hard coded path, something like here: also I will check if I ruby is able to load a dll in general, test some windows API calls from kernel32.dll or so, will report back if I found something Regards, |
|
If you are installing from source the hardcoded path should be ok. If you need to have relocatable packages, you can enable the |
|
Hmm I found something interesting, the only dynamic link library able to load from ruby which was generated by the gazebo project was gz-tools2-backward.dll, all others fail to load, so it is proved that it has something to do with the libraries itself, I will try to recompile that project and look into that |
|
@traversaro Ok, I got it running and I know now what causes the Libraries are not found message, at least for my package configuration, I did a recompile yesterday and after this it was working, for a self written plugin I had to install opencv dependency and this package was downgrading protobuf, after this I had to recompile gazebo, when it was finished the same error popped up again (Libraries are not found), remove opencv and install newer protobuf and recompile it again did make it work again. So here is a console output from it working: I will now test with GUI, for this I will compile either OGRE1.x or OGRE2.x into Gazebo as both of them compiled in seems to make problems --> Will report back. Regards, |
|
Running the GUI fails for me on both OGRE1.x and OGRE2.x, a window opens but does not respond anymore after a few seconds, sadly there are no more error messages to collect from console. I will close this now and I hope it will help someone who also has problems with libraries not found. @traversaro thanks for your help For anyone wondering, to build gz-rendering7-ogre2.dll I was using this SDK package https://github.com/OGRECave/ogre-next/releases/download/v2.3.1/ogre-sdk-v2.3.1-vc19-x64.7z and installed it manually in my environment, as the package provided by conda seems to be library incomplete but the library naming is the same like OGRE1.x is using so you can eighter build with OGRE1.x or OGRE2.x if you want to do it that way. And I used VS 2022 to build it, however the supported platform is VS 2019 Regards, |
I guess this is similar to #2089, even if nothing is printed on the console probably you can get some useful info from the file |
I don't have a ogre2 or ogre.log, I have auto_default.log with endless entries of So that's why my GUI is busy all the time! |
|
Ok finally I did it:
|
Environment
DxDiag.txt
Description
Output
gz sim -s -r --iterations 2 worlds\example_photo_shoot.sdf -v 3Library error for [D:/gazebo_sim-main/workspace/install/bin/gz-sim7-gz.dll]: No such file or directory
The text was updated successfully, but these errors were encountered: