Undefined Symbol

[KASUYASU]

Hi,

I built Cyclone DDS according to Getting Started, but it stops with an undefined symbol error.

~$ git clone https://github.com/eclipse-cyclonedds/cyclonedds.git
Cloning into 'cyclonedds'...
....
~$ cd cyclonedds/
~/cyclonedds$ mkdir build
~/cyclonedds$ cd build/
~/cyclonedds/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
-- The C compiler identification is GNU 11.4.0
...
-- Generating done
-- Build files have been written to: /home/***/cyclonedds/build
~/cyclonedds/build$ cmake --build .
[ 0%] Building C object src/tools/idlpp/CMakeFiles/idlpp.dir/src/directive.c.o
...
[ 76%] Built target libidlc
[ 77%] Generating ddsperf_types.c, ddsperf_types.h
../../../bin/idlc: symbol lookup error: ../../../bin/idlc: undefined symbol: generate_type_meta_ser
gmake[2]: *** [src/tools/ddsperf/CMakeFiles/ddsperf_types_generate.dir/build.make:76: src/tools/ddsperf/ddsperf_types.c] Error 127
gmake[1]: *** [CMakeFiles/Makefile2:553: src/tools/ddsperf/CMakeFiles/ddsperf_types_generate.dir/all] Error 2
gmake: *** [Makefile:156: all] Error 2

Why?

Kaz

[eboasson]

It is a bit of a guess, but is it possible that you have (an old) Cyclone DDS installed elsewhere (e.g., via ROS 2) and that the LD_LIBRARY_PATH environment variable includes the directory containing that version's libcycloneddsidl.so?

If so, setting LD_LIBRARY_PATH to nothing before calling make should fix it.

This is an issue that has plagued other people as well. I'm sure there's a good way to force the new build to use the new library but no one's gotten around to fixing it for once and for all.

[KASUYASU]

Hi,

Thank you, Mr. eboasson.
It's Bingo!

This is an issue that has plagued other people as well. I'm sure there's a good way to force the new build to use the new library but no one's gotten around to fixing it for once and for all.

But is it so difficult to modify CMakeLists.txt to generate 'LD_LIBRARY_PATH = ' in Makefile ?

Kaz

[eboasson]

But is it so difficult to modify CMakeLists.txt to generate 'LD_LIBRARY_PATH = ' in Makefile ?

I think it is doable, but not entirely trivial either: https://stackoverflow.com/questions/35029277/how-to-modify-environment-variables-passed-to-custom-cmake-target . I'd also have to check macOS and Windows, although in practice the problem seems to surface only on Linux (might have something to do with the size of the user base 🙂) and so setting LD_LIBRARY_PATH would be an effective (albeit inelegant) solution for nearly everyone in practice.

There is also this: #1696, I think that would also fix it. It is still open because no-one gave me any feedback and yet I don't know CMake all that well and there is an obvious downside to that change as well (it will lead to old stuff remaining on the system even though it probably will never be used again).

And so once again the perfect has been the enemy of good enough!