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

Stephen Checkoway s at pahtak.org
Wed Mar 20 09:14:06 PDT 2013


On Mar 19, 2013, at 12:03 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:

>> What version of cmake are you using? I am getting the opposite
>> behavior: every binary is linked using -rdynamic :-(
> 
> BTW, I reported llvm.org/pr15543 to track this.


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.

-- 
Stephen Checkoway









More information about the llvm-dev mailing list