[llvm] r201921 - Use relative rpath so that the installation and build dirs are relocatable.

[David Fang]

> On 25 February 2014 20:35, David Fang <fang at csl.cornell.edu> wrote:
>> Hi,
>>         This patch is giving me runtime dyld errors on darwin8 (cmake+shared
>> build):
>>
>> [  6%] Building Intrinsics.gen...
>> dyld: Library not loaded: @rpath/libLLVMSupport.dylib
>>   Referenced from:
>> /Volumes/Isolde/builds/LLVM/gcc40-cmake-build/include/llvm/IR/../../../bin/llvm-tblgen
>>   Reason: image not found
>> make[2]: *** [include/llvm/IR/Intrinsics.gen.tmp] Error 133
>> make[1]: *** [include/llvm/IR/CMakeFiles/intrinsics_gen.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> because:
>>
>> % otool -L bin/llvm-tblgen
>> bin/llvm-tblgen:
>>         @rpath/libLLVMSupport.dylib (compatibility version 0.0.0, current
>> version 0.0.0)
>
> that looks correct. What is the rpath in llvm-tablgen? I get:

While it may be 'correct' on more recent darwin, darwin8 doesn't 
understand @rpath.

> $ otool -L ./bin/llvm-tblgen
> ./bin/llvm-tblgen:
> @rpath/libLLVMSupport.dylib (compatibility version 0.0.0, current version 0.0.0)
>
> $ otool -l ./bin/llvm-tblgen
> Load command 18
>          cmd LC_RPATH
>      cmdsize 40
>         path @executable_path/../lib (offset 12)
>
> $ otool  -l lib/libLLVMSupport.dylib
> Load command 3
>          cmd LC_ID_DYLIB
>      cmdsize 56
>         name @rpath/libLLVMSupport.dylib (offset 24)

I get (snipped):
...
Load command 9
           cmd LC_LOAD_DYLIB
       cmdsize 52
          name @rpath/libLLVMSupport.dylib (offset 24)
    time stamp 2 Wed Dec 31 16:00:02 1969
       current version 0.0.0
compatibility version 0.0.0
Load command 10
           cmd LC_LOAD_DYLIB
       cmdsize 56
          name @rpath/libLLVMTableGen.dylib (offset 24)
    time stamp 2 Wed Dec 31 16:00:02 1969
       current version 0.0.0
compatibility version 0.0.0
...

with *no* LC_RPATH.

>> The old 'set( CMAKE_INSTALL_RPATH "\$ORIGIN/../lib")' used to work fine.
>
> Old OS X used $ORIGIN? That is the ELF path.

My mistake, not $ORIGIN.
The previous cmake+shared builds used nonrelocatable absolute paths to 
the build area, looked like this:

[fangism:build/stage1/lib] fang% otool -L libLLVMTableGen.dylib
libLLVMTableGen.dylib: 
/Volumes/Isolde/fink.build/llvm34-3.4-0e/build/stage1/lib/libLLVMTableGen.dylib 
(compatibility version 0.0.0, current version 0.0.0)
         /sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0, 
current version 5.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 88.1.12)
         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current 
version 1.2.3)

/Volumes/Isolde/fink.build/llvm34-3.4-0e/build/stage1/lib/libLLVMSupport.dylib 
(compatibility version 0.0.0, current version 0.0.0)
         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 7.4.0)
         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current 
version 1.0.0)

Then at cmake-install time, I'd fix-up the install_names.
( script posted in http://llvm.org/bugs/show_bug.cgi?id=14905 )


>> I suppose I could attempt to conditionally use the old behavior depending on
>> host OS X version?  Or can I also use @executable_path/../lib as
>> CMAKE_INSTALL_NAME_DIR?
>
> What do you get with the configure build if you do a shared build?

I don't have a configure build.  Wasn't happy with how it did shared 
libraries (lack of GNU libtool) before but that was years ago, and I've 
since patched some cmake files.  Might try again in the future.

So using CMAKE_INSTALL_NAME_DIR = @executable_path/../lib seems to work 
well, and lets me run binaries from the build directory.
Then installation follows the same directory structure as the build dir, 
so it works fine.  Is there anything bad about linking this way?


David


-- 
David Fang
http://www.csl.cornell.edu/~fang/