cmake and RPATH
thiago at kde.org
Thu Feb 16 16:08:02 CET 2006
Alexander Neundorf wrote:
>> LD_LIBRARY_PATH doesn't work on a standard build.
Let me just rephrase: doesn't work on a standard KDE build, because we set
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
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
>> LD_LIBRARY_PATH is a no-op unless you give the compiler the option
>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
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
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
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060216/fa1a99af/attachment.pgp
More information about the Kde-buildsystem