[Gllug] library includes and compiling

[Nix]

On Mon, 14 Jan 2002, tet at accucard.com said:
>>-rpath is a bad idea on systems running the GNU libc, because it bans
>>you from moving those shared libraries around. If you leave out the
>>-rpath, the ld.so.cache and ld.so.conf are consulted, so the libraries
>>can move freely as long as the ld.so.conf is kept up to date; if you
>>include -rpath, the program simply breaks if the X libraries ever move,
>>and you must relink.
> 
> You learn something new every day. I was under the impression it did
> the logical thing (i.e., *added* a directory to the run path, so both

IIRC it doesn't.

[checks]

And I RC wrongly; glibc-2.2.4/elf/dl-load.c:_dl_map_object() is
unequivocal, and the _DT_RUNPATH or _DT_RPATH info (which -rpath sets)
is prepended to the list from ld.so.cache.

So ld.so.cache is searched if those directories don't exist.

Sorry for the misinformation.

(But it was true once: a check in CVS indicates that before this fix:

,----
| 1998-09-12  Andreas Schwab  <schwab at issan.informatik.uni-dortmund.de>
[...]
| 	* elf/dl-load.c (env_path_list): Renamed from fake_path_list.  All
| 	uses changed.
| 	(_dl_init_paths): Always set env_path_list from LD_LIBRARY_PATH,
| 	instead of appending it to the main map's rpath info.
| 	(_dl_map_object): Consistently use LD_LIBRARY_PATH after all
| 	DT_RPATHs.  This makes it effective again.
| 	(decompose_rpath): Remove second parameter, callers changed.
| 	(fillin_rpath): Allocate enough space in curwd.
| 	(expand_dynamic_string_token): Cope with get_origin returning -1.
`----

if a DT_RPATH existed, it would have turned off searching for that
library everywhere else except for LD_PRELOAD and /etc/ld.so.preload :(
which would not have been ideal.

But this was fixed before glibc-2.1 was released, so I'm talking
balls. Don't use -rpath if there's a chance your binary will have to run
on a glibc-2.0 system, that's all :)

> the rpath directories *and* those in ld.so.conf/cache were checked
> for the appropriate libraries). Indeed, ld(1) implies it does add it
> to the path, and ld.so(8) actively suggests both will be searched. I

And the source agrees :)

Again, sorry for misleading you; well done for not believing me
(believing me is a silly idea at the best of times ;) ).

> certainly didn't expect the presence of an rpath to inhibit the lookup
> in ld.so.cache. Is there some logic behind the current (apparently
> braindead) behaviour?

'Twas a bug, which I mistakenly thought was unfixed and was a feature ;)

> PS. Since there are almost certainly poeple on the list that know more
>     about such things than I do, anyone care to explain the difference
>     between DT_RPATH and DT_RUNPATH?

Fuck knows. I've been wondering about that one for a while.

Hm. Since I'm wandering around the sources anyway...

[read read]

They look to me (from the ELF spec and from bfd/elflink.h) as though
they're identical, save that one is deprecated and the other is not :)

-- 
`Perhaps you should have asked Santa for your program as a Christmas
present.' --- Terran Melconian

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug