Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undefined Symbol #1868

Open
KASUYASU opened this issue Nov 1, 2023 · 3 comments
Open

Undefined Symbol #1868

KASUYASU opened this issue Nov 1, 2023 · 3 comments

Comments

@KASUYASU
Copy link

KASUYASU commented Nov 1, 2023

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
Copy link
Contributor

eboasson commented Nov 1, 2023

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
Copy link
Author

KASUYASU commented Nov 1, 2023

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
Copy link
Contributor

eboasson commented Nov 2, 2023

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants