Closed CharlesJQuarra closed 10 months ago
Hello, thank you for the report!
The first thing would probably be to check if the library is being built correctly and if the symbol actually exists in the library, for example on my machine
$ find . -name libcpptrace.so
./libcpptrace.so
$ nm ./libcpptrace.so | grep generate_trace
0000000000057873 T _ZN8cpptrace14generate_traceEj
There's a good chance the symbol could be discarded if the compiler thinks it's not used, which I ran into briefly on windows. There's a fix in #24 (which is a work-in-progress but hopefully can be merged soon) but I can apply a hot-fix on the main branch if needed.
Hi Jeremy, it seems I updated the issue while you were replying, the updated message shows the symbols are indeed present
Oh it looks like it, thanks! This is then very puzzling 😄 The link order looks fine to me. I tried a simpler version of the same command locally and it builds fine. If you try something like this, does it work for you? (Where foo.cpp is just a dummy program that calls cpptrace::generate_trace)
g++ foo.cpp -o foo.o -c -Iwherever
g++ foo.o -Lwherever -Wl,-rpath,wherever libcpptrace.so -o foo -Wl,--as-needed -rdynamic
The original successful test example I had was linking like this:
/usr/bin/c++ -g -DENABLE_DEBUG_MACROS -rdynamic CMakeFiles/simple.dir/src/simple_test.cpp.o -o simple -Wl,-rpath,/home/charlesq/Projects/testbt/build/_deps/cpptrace-build -lasan -ldl -lrt -ltinfo -lpthread -lm -lunwind _deps/cpptrace-build/libcpptrace.so
which is similar to yours, except in yours the -rdynamic
option comes after the libraries, I tried to see if there is some way in cmake to add link options in specific order relative to libraries but I couldn't find one. But since it works in the test example perhaps the order of that specific option is not essential
g++ foo.cpp -o foo.o -c -Iwherever g++ foo.o -Lwherever -Wl,-rpath,wherever libcpptrace.so -o foo -Wl,--as-needed -rdynamic
I'm pretty puzzled by what's going on here. I'll think on it a little more but I'm not immediately thinking of anything else. If there's a way I could reproduce locally that'd be helpful.
I'm pretty puzzled by what's going on here. I'll think on it a little more but I'm not immediately thinking of anything else. If there's a way I could reproduce locally that'd be helpful.
I spent half my day trying to reproduce the undefined reference of the complex project into the test project by adding all the dependencies like libtorch, opencv, etc. and nothing I brought resulted in the problem happening
I gave up and decided to install cpptrace system-wide, and using find_package() and the cpptrace::cpptrace target now links and works correctly on the complex project.. The only reason I could discern is that using FetchContent_MakeAvailable the library is added as relative path "../_deps/cpptrace-build/libcpptrace.so", but running the linking command directly with the full path didn't help. It bothers me that it would work with the system-wide installation but not the other, but the only lead is that perhaps the cmake scripts being installed are doing something different than the FetchContent strategy?
That I'm not sure, I thought FetchContent relied on the same definitions that cmake uses for the install target. I would not expect a relative or absolute path to cause an error here for the linker step at least.
Hi @CharlesJQuarra, I'm going to close this issue for now since a lot of time has passed and also a lot has changed in the library. There's a chance if things never ended up resolved on your end, it may work now or when the next release comes out.
Hi,
I successfully tested yesterday cpptrace on a test app with cmake and FetchContent_MakeAvailable. I went ahead to integrate it into a more complex cmake project using exactly the same strategy, but I kept getting
I tried literally everything I could think of to debug the issue: from adding the hardcoded path as
target_link_directories
and hardcoding the-lcpptrace
withtarget_link_options
, to moving it around, with no luck.Needless to say, I checked the symbols are indeed present in the library:
I tried adding verbose options to the linker, but besides adding more contextual environment variables to the console output, there is really no hint on why it failed to find the linker reference
One of the libraries I'm depending was an older version of libtorch, and after reading a while, I noticed that since a few versions ago it started shipping with both pre-CXX11-ABI and CXX11-ABI builds, so just in case this was causing the incompatibility, I updated the libtorch version with one built with c++11 ABI, but the same problem keeps happening. In any case I tried this despite there is no hint the source of the linker failure was even remotely related to an ABI incompatibility, just because some people on the internet seemed to have similar mysterious undefined reference errors that were related to this.
I've tried to read more on how to debug linker errors, but it seems there is not a lot of available information short of becoming an amateur compiler developer myself. Do you have any better ideas how could I debug this error?
This is the linker command in question with lots of verbose output: