simCreateCollection linking problem?

[peci1]

Hello, I just updated to 3.2.1 and wrote a plugin which uses the newly added simCreateCollection C API function.

The code compiles and links well, but when I start V-REP, the plugin fails to load. I verified it is caused exactly by this line of code. And it is not a runtime problem, since this line is not part of the v_repStart function.

[coppelia]

Hello,

is there a message that says why the plugin will not load?
The V-REP functions are linked and resolved dynamically. If a function cannot be found in the V-REP library, a specific message will be output.

Maybe you are still using the older V-REP library?

Cheers

[peci1]

is there a message that says why the plugin will not load?

No, just "the plugin failed to load, check ldd output". But ldd shows no unresolved stuff.

Maybe you are still using the older V-REP library?

I checked the /opt/vrep/libv_repLib.so and it's modification date is May 4, which should be the newest version.

[coppelia]

Since the V-REP functions are linked and resolved at runtime (in loadVrepLibrary and getVrepProcAddresses), this can't be your problem. It must be something else, some other dependency your plugin is relying on (some Qt components? Different Qt version?).

Cheers

[peci1]

I know it doesn't make sense, but look at this:

Code: Select all

    int vrepVer;
    simGetIntegerParameter(sim_intparam_program_version,&vrepVer);
    if (vrepVer<30201)
    {
        std::cout << "Sorry, your V-REP copy is somewhat old. Cannot start 'ROS' plugin.\n";
        unloadVrepLibrary(vrepLib);
        return(0); // Means error, V-REP will unload this plugin
    }
    // ******************************************

    std::cout << &simCreateCollection << " addr";

This piece of code causes the loading problems. If I exchange `simCreateCollection` with e.g. `simCreateDummy`, the library loads.

I also tried if the version check works (by changing it to `vrepVer < 30202`, and in this case V-REP told me I have old version; so when there is 30201, I can be sure that the loaded library is really 3.2.1).

But when I run

Code: Select all

std::cout << _getProcAddress(vrepLib, "simCreateCollection");

I get a non-zero address ( 0x7fc367fff2f0 ).

I really don't understand what's going on.

[coppelia]

That is indeed very strange.
I have tried to use a plugin that prints the address of simCreateCollection, on Windows and Linux, and the plugin just loads and runs fine. There must be something else in your plugin that messes things up..

Cheers

[peci1]

That is indeed very strange.
I have tried to use a plugin that prints the address of simCreateCollection, on Windows and Linux, and the plugin just loads and runs fine. There must be something else in your plugin that messes things up..

Cheers

Okay, found the culprit.

It was in CMakeLists.txt . I started with the vrep_plugin_skeleton and edited it to my needs. As one of the edits, I removed `src/v_repLib.cpp` from the `add_library` call. It made no sense to me to include an external file into my plugin. Still it remains unclear to me why some functions worked and some of them not.

However, I still think the whole concept V-REP uses in plugins (copying of header and even source files) is completely wrong and I really dislike it. So at least in ROS, I set up an environment variable VREP_ROOT_DIR and now the only thing I need to do in my CMakeLists.txt is

Code: Select all

set(VREP_ROOT_DIR $ENV{VREP_ROOT_DIR})

include_directories(
    ${VREP_ROOT_DIR}/programming/include
)

target_link_libraries(v_repExtTradr
    ${VREP_ROOT_DIR}/libv_rep.so
)

This way, no header files need to be copied, nor do the cpp files (because I directly link the SO library from V-REP installation directory).

[peci1]

I was thinking about it a bit more, and the whole dynamic loading of the V-REP library is unclear to me.

What is the reason of dynamically loading lib_vrep.so instead of dynamically linking it during build? Are there any advantages?

[coppelia]

Well, after the years, it is difficult to say why exactly. But in the end, it seemed an easier and more flexible solution across platforms, and also allows to output messages about missing function definitions instead of simply not loading.

Cheers

[peci1]

There's another finding in this problem I made.

I used a wrong expression to write out the address of `simCreateCollection`.

Instead of

Code: Select all

std::cout << &simCreateCollection

it should be

Code: Select all

std::cout << (void*)simCreateCollection

(the first version writes out the address of the pointer to the function).

Using the correct address-writing call, I discovered simCreateCollection really points to zero in my case (just adding this debug call to the vrep_plugin_skeleton, nothing else changed).

Further, I discovered vrep_plugin_skeleton doesn't make any use of the compiled-in v_repLib.cpp file (I can edit it freely, add some debug printouts, and nothing has an effect).
It makes sense to me, since getVrepProcAddresses is a global function, and if it is defined and loaded earlier by any other piece of code (probably a plugin), then it is not overwritten by the new definition.
So my feeling is that some other library is compiled with the old 3.2.0 version of v_repLib.cpp which doesn't load the newly added functions. However, I checked all my loaded plugins and none of them seems to use the old version in its source.

If I call

Code: Select all

simCreateCollection = (ptrSimCreateCollection)_getProcAddress(vrepLib,"simCreateCollection");

before I call simCreateCollection, then everything works as expected.