cmake and RPATH

[Thiago Macieira]

Alexander Neundorf wrote:
>> LD_LIBRARY_PATH doesn't work on a standard build.
>
>Why ?

Let me just rephrase: doesn't work on a standard KDE build, because we set 
-rpath.

Here's what happened:

in order to avoid setting LD_LIBRARY_PATH or /etc/ld.so.conf for every 
libdir you installed, someone came up with the idea of RPATH in the ELF 
header. You get that when you use the -rpath option to the linker 
(-Wl,-rpath to the compiler, or simply -R to libtool).

What it does is that it adds a list of dirs that the dynamic linker should 
search *first*.

What no one realised at that time was that searching RPATH before 
LD_LIBRARY_PATH was a bad design decision. So, the ELF header with RPATH 
always overrides LD_LIBRARY_PATH.

When they realised that, they invented a new ELF header entry: RUNPATH. 
This one has the proper behaviour: it allows you to set a default, but it 
still allows LD_LIBRARY_PATH to override it.

However, the linkers do not emit this entry by default. You have to tell 
them to do it by using the --enable-new-dtags switch to GNU ld 
(-Wl,--enable-new-dtags to gcc). If it's not GNU ld, you cannot rely on 
it existing.

>> LD_LIBRARY_PATH is a no-op unless you give the compiler the option
>> -Wl,--enable-new-dtags.
>
>LD_LIBRARY_PATH doesn't work without special flags to the linker ?

LD_LIBRARY_PATH works on a normal (non-KDE) link
LD_LIBRARY_PATH doesn't work if you use -rpath to the linker (which we do)
LD_LIBRARY_PATH works again if you use --enable-new-dtags

>> GNU ld has supported it for quite a few years,
>> but I have no idea how the non-GNU linkers on ELF platforms do.
>
>On OS X (which is non-ELF) there's DYLD_LIBRARY_PATH.

Which is orthogonal to the discussion. I was referring to the ELF linkers 
that aren't GNU ld, such as the ones you're likely to find on Solaris.

So, let me repeat: in order to support proper build, cmake has to either:
1) enable --enable-new-dtags
or
2) relink

There is no other solution that I can see. And also note that, since 
option #1 may not be available in all platforms, cmake has to support 
option #2 anyways. 

Which binary cmake chooses to relink, that's its own choice. It could 
relink the binary it install or it could relink the one you try to run 
before installing. It could also have a "developer mode" in which it will 
build both.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

1. On frumscafte, hwonne time_t wæs náht, se scieppend þone circolwyrde 
wundorcræftlíge cennede and seo eorðe wæs idel and hit wæs gód.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060216/fa1a99af/attachment.pgp