Subject: Re: static vs. dynamic runtime linking, again (was: PAM and su -K)
To: None <tech-userlevel@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-userlevel
Date: 01/24/2005 19:59:24
>>> The conclusion is that their authors should just forget
>>> LD_LIBRARY_PATH + /etc/ld.so.conf and repair their build
>>> frameworks.
>> And just what do you think I should do to "repair" my build
>> "framework" - which you, NetBSD, not I, broke?!
> NetBSD didn't break anything;

It used to work on older NetBSD.  It doesn't work on current NetBSD.

That's the sense in which NetBSD broke it.

> this is the standard way dynamic linking works for ELF objects.  It
> struck me as a little bit strange too -- 10 years ago, when it was
> genuinely new or unusual.  Now that I've managed to accept it as the
> norm, I can see that it has decided advantages

The flexibility it provides has decided advantages.

The way it is implemented in 2.0 is rather broken, even if only in the
way it defaults things.

> ELF doesn't work quite like a.out did in terms of loading
> dependencies.  In ELF, there are both a per-executable "run path"
> which will be searched to find each named dependency, and,
> per-dependency, a name.  The run path is explicit, and is part of the
> built executable; it is not implicit in some magical way, pulled from
> a configuration file in /etc, or so forth.

Then unless given an option that includes "suppress the warning"
semantics, the linker needs to warn when it is linking a program in
such a way that it will not work to run it immediately, preferably
including what needs to be done to change that.

> -R is how you set the run path in an executable.

The warning I mention above should say this, then.  Really, the simple
way of specifying the library path needs to set both the link-time path
and the run-time path, to avoid this "buh-but I just linked it and got
no errors, why can't it now find the library it found a moment ago?"
effect.

Now, perhaps -L has those semantics.  But it shouldn't, because it used
to be "add this to the library search path", and silently changing the
semantics of an option so that formerly working things silently fail
is, well, broken.

For the sake of the flexibility you (correctly, IMO) like, it needs to
be possible to specify the two paths independently (and to override the
linked-in run-time path at run time).  But the defaults should Just
Work for the common case.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B