[SOLVED] MeshSTEPLoader plugin loading failed

[CamilleK]

Hello everyone,

I’m trying to use the MeshSTEPLoader plugin, in order to import a geometry from a STEP file into SOFA.
I successfully built SOFA with the plugin activated, but an error occurs when launching runSofa announcing that the plugin could not be loaded.

The output when launching runSofa is :

[ERROR]   [PluginManager] Plugin loading failed (C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll): Le module spÚcifiÚ est introuvable.

Going a bit more into details in Debug mode, the file MeshSTEPLoader.dll is indeed found by the PluginManager, but seems to not be properly handled when reaching the Windows level of loading.

Here is the detail of my setup :
– SOFA built from the master branch of the Git repository (commit 2e29258, on 2017-11-22)
– CMake v3.7.0
– Boost v1.62.0
– Qt v5.6.2
– Built on Windows 10 (version 1607) x64, with Microsoft Visual Studio Community 2015 (version 14.0.25431.01 Update 3)

I also built separately the OpenCascade library, on which the plugin relies. The most recent version I found compatible with the implementation of the MeshSTEPLoader plugin was v6.7.1, but it resulted in too many building errors – which I assumed came from incompatibility with my (more recent) compiler version.
I turned to the latest version of OpenCascade (v7.2.0) which (apparently) I successfully built and linked with SOFA.
Build of the MeshSTEPLoader project required a few minor changes in order to adapt to the more recent version of SOFA and OpenCascade, but unless I missed something, they were straightforward.

I tried to have a look at the CMakeLists.txt file of the MeshSTEPLoader plugin, but my CMake understanding is limited to the basics and I didn’t encounter anything that could explain why the plugin can’t be loaded.

Has this situation happened before with the MeshSTEPLoader plugin? And do you know what I’m missing?

Best regards,

Camille

Edit: I couldn’t put the rest of the console output because it was considered as spam, but there was nothing unusual except for this error line

[Hugo]

Hi Camille

Thank you for posting this issue.
Your the second person today mentioning this issue of non-loaded plugin on Windows. We will investigate this asap. For sure what you can do temporarily is to add the associated lib (dll) in Edit->PluginManager->Add..

Moreover, it would be great if you could share (pull-request) the update you did on the MeshSTEPLoader plugin with the latest version of OpenCascade !

I’ll get back to you as soon as possible, to follow the discussion on GitHub: https://github.com/sofa-framework/sofa/issues/558
Best,

Hugo

[CamilleK]

Hi Hugo,

Thanks for your answer.

I tried to manually add the MeshSTEPLoader.dll via Edit->Plugin Manager->Add, but it resulted in the same error: a new window was displayed (“library loading error”) on which there was the same text (“Plugin loading failed (C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll): Le module spÚcifiÚ est introuvable.”).
The console output is also identical.

Going into the code, it seems to me that this error does not occur at the SOFA level. More precisely, when the plugin is loaded, the call stack gives something like this :
– line 122 of SofaPluginManager.cpp > call to method
loadPluginByPath(pluginFile,&sstream)
of the PluginManager, with pluginFile=”C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll”
– line 148 of PluginManager.cpp > call to method
load(pluginPath)
of the DynamicLibrary (pluginPath=”C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll”)
– line 74 of DynamicLibrary.cpp > call to the Windows routine ::LoadLibraryA(filename.c_str())
(filename=”C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll”)

Apparently the pointer returned by this last routine is NULL, which triggers the display of the error message I’m getting.
The beginning of the call stack is slightly different when I get the error while launching SOFA, as the plugins are automatically loaded, but in the end the behaviour is the same.

I’m not yet familiar with the pull-request process and the contributions to SOFA, but I’ll be sharing the update on the MeshSTEPLoader plugin as soon as possible!

Best,

Camille

[Hugo]

Great Camille! Nice to read that you are in the open-source spirit!

I will ask a dummy question : is the library MeshSTEPLoader.dll really generated/present in your build of SOFA (i.e. in the folder build/lib/) or anywhere else in your buid

Best,

Hugo

[CamilleK]

Hi Hugo,

I should have mentioned it actually, but yes the .dll file is indeed generated, and it is in the folder where the PluginManager is looking at by default (build/bin/RelWithDebInfo/MeshSTEPLoader.dll). I don’t know if it is worth mentioning, but the static library is generated as well in a different folder (build/lib/).

In fact, just before the call to the load method is made in PluginManager.cpp, a test is run:
FileSystem::exists(pluginPath)
with the same path I mentioned before, and it returns “true”.

As I don’t understand this error, I’ll try to build and run SOFA in Debug or in Release mode, to see if it changes something (I’m currently in Release with Debug info)

Best,

Camille

[Hugo]

Good idea, since this plugin is rarely used maybe a problem in the CMakeList file.
I will try to compile it on Linux to see if I can use it.

Best,

Hugo

[Hugo]

[Update]
All the GitHub discussion is going on here: https://github.com/sofa-framework/sofa/issues/561

Best,

Hugo

[CamilleK]

Hello Hugo,

Sorry for the delay. I had a look at the GitHub discussion, but I’m not sure the problem I have is the same.

I tried to update my Sofa sources with a more recent commit (573fc41 from 2018-01-14), and it resulted exactly in the error message Erwan Douaille first mentioned in the GitHub discussion (#561).

I then switched back to the former commit I was based on (2e29258, from 2017-11-22). I have indeed extra repositories (Debug, Release, RelWithDebInfo) added by Visual Studio in the build/bin repository, but most plugins are nonetheless successfully loaded (it’s the case for SofaPython, SofaSphFluid, SofaMiscCollision, image, Compliant, Flexible, CImgPlugin and SofaAllCommonComponents). Only the MeshSTEPLoader triggers the error I’m facing.
In addition to that, the plugin_list.conf is correctly generated and found by Sofa at execution time. In my case it is this file that triggers the automatic loading of all the plugins I mentioned above.

Based on this, I would say that the problem I’m facing seems older than the one discussed in the associated GitHub issue. Do you think it is possible that the two issued are not directly related?
In any case I’ll follow closely the GitHub discussion and try again with the correction as soon as it is available.

Best,

Camille

[ErwanDouaille]

Hey @CamilleK,

I did a fix yesterday about it. Can you try it and let us know if it fix your problem ?

https://github.com/sofa-framework/sofa/issues/561
Edit: Sorry, bad link. Here is the correct one : https://github.com/sofa-framework/sofa/pull/564

Thanks in advance for your feedback 🙂

[CamilleK]

Hi Erwan,

Thanks, I hadn’t notice the PR at the end of the GitHub discussion. I tried again with the fix, adding the modifications I had done to adapt the MeshSTEPLoader (which rose no conflict). The build went with no error, but the execution of runSofa failed to load several plugins, for instance :

[ERROR] [PluginManager] Plugin loading failed (C:\dev\sofa\master\bd\bin\RelWithDebInfo/.\/SofaPython.dll): La procÚdure spÚcifiÚe est introuvable.
(I’ll try to edit with the complete output, but for the moment it is considered as spam)

As for the MeshSTEPLoader plugin, the behaviour seems to be exactly the same as I had before.

[CamilleK]

[Update]
Finally I found the problem (which was a bad mistake on my side).

During the tests I did, I compiled the OpenCascade library in different modes (Release, Debug, RelWithDebInfo) and for different versions. The problem came from the fact that the Release and Debug mode generate libraries in separate folders, and at some point the Release folder which I was using in my PATH was emptied.
Building once again OpenCascade in Release mode allowed my PATH to be correct again, and solved this issue. Sorry for taking your time with this…

I’ll test my updated MeshSTEPLoader, and share it as soon as possible. In the meantime I’m setting this issue to solved

Thanks for your help!

[Author]

Posts