bugpoint (and possibly others) need to be compiled with -rdynamic

While running the llvm tests, I get several error messages like these:

[1/1] Running the LLVM regression tests
FAILED: cd /home/steve/llvm-build/test && /usr/local/bin/python /home/steve/llvm/utils/lit/lit.py --param build_config=. --param build_mode=Release -sv --param
llvm_site_config=/home/steve/llvm-build/test/lit.site.cfg --param llvm_unit_site_config=/home/steve/llvm-build/test/Unit/lit.site.cfg /home/steve/llvm-build/tes
t
-- Testing: 6378 tests, 4 threads --
Testing: 0
FAIL: LLVM :: BugPoint/metadata.ll (351 of 6378)
******************** TEST 'LLVM :: BugPoint/metadata.ll' FAILED ********************
Script:

Attached is a patch that fixes it for the cmake build. I'm not positive this is the right place to put it and I really have no idea where the check should go when using the autotools.

llvm-rdynamic.patch (663 Bytes)

What version of cmake are you using? I am getting the opposite
behavior: every binary is linked using -rdynamic :frowning:

Cheers,
Rafael

What version of cmake are you using? I am getting the opposite
behavior: every binary is linked using -rdynamic :frowning:

BTW, I reported llvm.org/pr15543 to track this.

Cheers,
Rafael

When I first sent the email (in August of last year), I was using cmake 2.8.8. I now appear to be using 2.8.9 and I don't have the same behavior you do:

steve$ ninja -v -j1 bin/llvm-as
[1/1] : && /usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Wno-uninitialized -Wnon-virtual-dtor -fno-rtti tools/llvm-as/CMakeFiles/llvm-as.dir/llvm-as.cpp.o -o bin/llvm-as -L/usr/local/lib lib/libLLVMAsmParser.a lib/libLLVMBitWriter.a lib/libLLVMCore.a lib/libLLVMSupport.a -lrt -lpthread -Wl,-rpath,/usr/local/lib:

Switching compilers makes no difference (and I wouldn't think it would):

steve$ ninja -v -j1 bin/llvm-as
[1/1] : && /usr/bin/clang++ -fPIC -fvisibility-inlines-hidden -Wcovered-switch-default -Wnon-virtual-dtor -fno-rtti tools/llvm-as/CMakeFiles/llvm-as.dir/llvm-as.cpp.o -o bin/llvm-as -L/usr/local/lib lib/libLLVMAsmParser.a lib/libLLVMBitWriter.a lib/libLLVMCore.a lib/libLLVMSupport.a -lrt -lpthread -Wl,-rpath,/usr/local/lib: && :

The difference seems to be Linux vs. FreeBSD.

On Linux:
s$ cmake --version
cmake version 2.8.9
s$ grep rdynamic build.ninja |wc -l
56

On FreeBSD:
steve$ cmake --version
cmake version 2.8.9
steve$ grep rdynamic rules.ninja |wc -l
       0

Okay, yes that's it.
${prefix}/share/cmake/Modules/Platform/Linux-Intel.cmake:
  # We pass this for historical reasons. Projects may have
  # executables that use dlopen but do not set ENABLE_EXPORTS.
  set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-rdynamic")

I assume the CMAKE_SHARED_LIBRARY_LINK_C_FLAGS and CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS could be set empty initially and then for those that need it, set it (or something else) to -rdynamic.

Attached is a small patch that sets CMAKE_SHARED_LIBRARY_LINK_CXXFLAGS to "" (as per your patch which I didn't notice initially), and then sets opt, bugpoint, and JITTests to have the property ENABLE_EXPORTS set to 1. This passes -Wl,--export-dynamic on BSD and Linux (and others) and --export-all-symbols on cygwin.

I'm not sure if there are others that should be modified as well. Presumably an option for clang would be easy enough to add.

symbols.patch (1.57 KB)

Attached is a small patch that sets CMAKE_SHARED_LIBRARY_LINK_CXXFLAGS to "" (as per your patch which I didn't notice initially), and then sets opt, bugpoint, and JITTests to have the property ENABLE_EXPORTS set to 1. This passes -Wl,--export-dynamic on BSD and Linux (and others) and --export-all-symbols on cygwin.

I'm not sure if there are others that should be modified as well. Presumably an option for clang would be easy enough to add.

This is awesome, thanks!

Chandler, is Stephen's patch OK? The trivial attached patch should
keep the status quo for clang, but I only have a OS X laptop with me
now, so I cannot test it.

--
Stephen Checkoway

Cheers,
Rafael

t.patch (400 Bytes)

This is awesome, thanks!

Chandler, is Stephen's patch OK? The trivial attached patch should
keep the status quo for clang, but I only have a OS X laptop with me
now, so I cannot test it.

I am back to my linux machine and was able to test this. It works
great. I have committed the clang change as 178723 and your patch as
178725.

Thanks,
Rafael