Some libraries are not found without LD_LIBRARY_PATH mangling

[Thiago Macieira]

Discussion moved from kde-core-devel. Link to thread:
http://lists.kde.org/?t=119343241900001&r=1&w=2

Em Monday 29 October 2007 16:45:01 Alexander Neundorf escreveu:
> > But can't we use the installed libraries for the commands used during
> > installation?
>
> You mean "used during building", right ?
> Not necessarily. The commands may use some new stuff or need bug fixes from
> the libs so they need to get the libraries from the build tree.

Yes, I meant that. But you're right: the application may need some new 
functionality from the library.

By the way, this is how Qt solves this problem for moc and uic: it *doesn't* 
link them to the Qt libraries. Those programs are "bootstrapped": that is, 
they add the .cpp files directly to their compilation, therefore linking 
statically to the Qt stuff they need. 

So in a typical Qt build, qstring.cpp is compiled 5 times: once for QtCore, 
then one more time per tool (moc, uic, rcc and qmake).

> > Another option: build those tools only with RPATH to the build tree, then
> > relink them (and only them) during installation. This requires a full
> > library list during linking: e.g., "-lkio -lkdeui -lkdecore", not just
> > "-lkio". Doesn't CMake already do that?
>
> Well, the issue is that potentially any of the libraries could be used by
> these tools, and it doesn't make sense to mark libraries as
> RUN_UNINSTALLED, because the developer of the library doesn't necessarily
> know that.
>
> CMake doesn't automatically detect which shared libraries are linked to
> executables which have an RPATH which points into the build tree, in order
> to guess to build these libraries also with RPATH pointing into the build
> tree.

What happens to a library marked RUN_UNINSTALLED?

My point is: only the program has to be modified to find the libraries when 
they aren't installed yet. The libraries themselves don't need to be modified 
at all.

So, when building a RUN_UNINSTALLED program, it is linked with full rpath to 
the build tree and full library list. That way, all libraries will be found 
in the build tree, even if the libraries themselves don't know anything about 
RUN_UNINSTALLED.

> > Maybe an even better option: set LD_LIBRARY_PATH when running
> > uninstalled. That variable overrides RUNPATH and any distribution not
> > using that (read: using RPATH only) should be shot in the head.
> > DT_RUNPATH has been available for more than 5 years.
>
> While it probably is available on most Linux systems today, I don't know if
> this is also true for *BSD, Solaris, HP-UX etc.

FreeBSD has been using RUNPATH exclusively for years. They have already dumped 
the old and conceptually broken DT_RPATH. This is what irks me: why the hell 
hasn't Linux done the same? Support for DT_RUNPATH has been around for 8 
years in glibc, some 5 years or more in the linker.

Of the platforms we can support, we have two groups:

AIX, MacOS X, Win32: their own executable formats
All others (Linux, the BSDS, Solaris, IRIX, HP-UX): ELF

I have no idea about AIX's file format. All I know is it's COFF-based (it's 
called XCOFF). Reading through the ld(1) man page on AIX indicates that the 
linker hardcodes the -L switches to the final executable. In other words: the 
AIX linker does not like linking to uninstalled libraries at all. It would 
indicate that relinking at install time is mandatory on AIX (so as to get rid 
of the build-tree references).

I also try to steer away from MacOS X's Mach-O format. It's very confusing. 
But I know it supports changing the linker paths of already-created 
executables without relinking.

As for Win32's COFF Portable Executable format, the interesting thing is that 
all we need to do is put the DLLs in the same directory as the executable 
itself. There's no need to relink: the same executable and same libraries are 
valid for uninstalled- and installed-execution. We do place them all in bin/, 
don't we?

For IRIX, it looks like DT_RUNPATH is not supported. It's not mentioned 
anywhere in the ld(1) or rld(5) manuals.

The same seems to apply to HP-UX.

For Solaris, it's using DT_RUNPATH on normal builds (Solaris 9 tested).

> I don't think CMake right now supports setting only RUNPATH but not RPATH
> due to this. Even if it would be implemented today, it wouldn't help us
> since we require CMake 2.4.5 for KDE 4.0.x.

There's no way to set only RUNPATH (without RPATH) without modifying the 
linker. But this is not anything that affects us: if DT_RUNPATH is present, 
the DT_RPATH entry *must* be ignored by the dynamic linker.

So, the search order is this, on ELF platforms:
	RPATH, unless RUNPATH is present
	system-specific environment variables (LD_LIBRARY64_PATH, etc.)
	LD_LIBRARY_PATH
	RUNPATH
	system configuration
	system defaults

> Having something like install_name_tool would be nice :-)
> There is chrpath but this is not widely installed and works only if the new
> RPATH is not longer than the original one, so it would need some support
> from the linker, so enough space is reserved. OS X does that.

I guess there's also a third option, which is what libtool used to do:

	relink at uninstalled-run-time

That is, if a program is run from inside its build tree, it's automatically 
relinked against the proper libraries.

So, let me summarise what I am proposing:

- on AIX: always relink at install time, regardless of any CMake settings
- on MacOS X: install_name_tool
- on Windows: no action necessary - at most, set PATH
- on ELF platforms with DT_RUNPATH (Solaris, Linux, BSDs):
  set LD_LIBRARY_PATH from a shell script and exec
  no relinking necessary
- on ELF platforms without DT_RUNPATH (IRIX, HP-UX):
  RUN_UNINSTALLED executables are relinked at install time

Also note that "link at install time" should mean "link twice at compile time" 
(except for AIX, where you *need* to install the libraries before you can 
link the executable), since you can run the executable in the build tree 
after installation.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20071030/313bb5b0/attachment.pgp