Re: [gentoo-alt] revdep-rebuild and install_name

[Fabian Groffen]

On 08-05-2007 14:48:15 +0200, Johan Hattne wrote:
>>>> b) I've been killing darwinistic specialties in ncurses and readline
>>>>    recently, on purpose
>>> :)
>>>
>>> Anyway, here's what I had in mind.
>
> Going out on a limb here, but this is how I understand the problem.
>
> (1) When linking against a shared/dynamic library the recorded dependency
> is taken from the -install_name option used when the library was built, or
> -o if -install_name was not supplied.  I guess the point is that if an
> executable is linked against a not-yet-installed library, it'll work once
> the library is installed.  So libraries can't just be moved from their
> install location, because everything that is and, interestingly, will be,
> linked against them will look for the libraries in their old place.

Ehm, yeah.  I think you got that right.  In general:
On all platforms we sort of record the location where a dynamic lib is
supposed to be in the binary that looks for it.  On Darwin this is a
path to the library itself, on Linux and Solaris (ELF systems) this is a
path to the directory where the library is, stored in the RPATH record.

> (2) In non-prefix, libraries typically end up in /usr/lib*.  If /usr isn't
> on the the same partition as /, there may be problems if something during
> boot needs /usr/lib to resolve its symbols.  Hence, some libraries need to
> be in /lib, and symlinks won't do.

The compiler, linker and runtime linker all default to /usr/local/lib,
/usr/lib, /lib to search for libraries.  This means, (also on Darwin in
a way) that if there is no path given for a dynamic library, it is
searched for in those three paths.  You can influence that by setting a
special variable, but that's in general considered to be a bad
practise.

The reason why stuff is in /lib and not in /usr/lib has to do with the
function the location.  /lib should always be available, /usr/lib can
get mounted (e.g. over NFS) only later, and hence can also become
unavailable.  Same for /bin and /usr/bin.  Hence, /bin/sh and
/usr/bin/bash on Solaris, as root uses /bin/sh, so /usr/bin/bash can
become unavailable safely to still rescue the system.  So for the
libraries.

In Gentoo the libraries are never copied, but on GNU/ELF systems,
LD-wrapper scripts are made.  Because Darwin (and more systems) don't
grok those scripts, we create symlinks for those systems.  The reason
why this is done, is because in some cases GCC decides to make a static
binary instead of a dynamic one if it doesn't see a dynamic library in
/usr/lib.  I don't know the details of this, it's what I know from the
eclass that does this creating of the wrapper or symlink.

>> ncurses patch: no way, the main tree does it like that, so not going to
>> change that.
>
> ncurses is configured with --libdir=/lib.  Then, whatever parts aren't
> needed in /lib are moved to /usr/lib, with the effect that moved items
> would no longer be found in /lib.  What I tried to do was to configure with
> --libdir=/usr/lib, move necessary things to /lib and create links where the
> moved things used to be.

That was an error.  Just recompile those things that now generate a
kernel trap.  It's a pain maybe, but it's really better to just get
through this.  I only had to recompile three packages or so, thusfar.

>> readline patch: I don't understand it
>
> readline is configured with --libdir=/usr/lib.  Then all libraries are
> moved to /lib.  I wanted to create symlinks for all libraries moved.  I
> guess the intention would have been clearer if I had configured with
> --libdir=/lib and skipped the move altogether (not tested).
>
> That was the idea and sorry for any confusion caused.

It's good to put it on the table.  I was a bit in a hurry when I
replied, so I forgot to say that I like the feedback.  I think there is
no better way than keeping all platforms aligned wherever this is
possible.  And this library location problem seems to be not a problem
on Darwin, but it does affect existing users, unfortunately.  However,
it is a one-time pain, and a risk of running the highly experimental
Gentoo Alt/Prefix project ;)

Thanks!

-- 
Fabian Groffen
Gentoo on a different level

-- 
gentoo-alt@g.o mailing list