On Mon, Jan 24, 2005 at 07:59:24PM -0500, der Mouse wrote:
> 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.

But the change in semantic is necessary, because the semantic of the
library itself changed. Consider an application build layout like this:

app/lib
app/src1
app/src2

Both the programs in src1 and src2 depend on lib. The "classic" way to
build it was:
- make in app/lib
- make in app/src1, linking with -L${.OBJDIR}/../lib -lfoo
- make in app/src2, linking with -L${.OBJDIR}/../lib -lfoo

Which is fine for a static compilation, but not for dynamic linking.
In a dynamically linked work, you *can't* embedded ${.OBJDIR}/../lib
in the executable as link path for very obivous reasons. There's a
different between the compile time location of a library and the
runtime location. One of the reasons for this is security, older
OSs did happily include ../lib as runtime path, with the consequences
it has (e.g. what is ../lib relative too?). How should the linker
know the difference between both locations? It can't, it can't
even guess. On Linux, FreeBSD, DragonFly and OpenBSD, this issue is
mostly ignored for "standard" locations like /usr/X11R6/lib, but
this is a band aid and hassle.

We had some strange bug in DragonFly back when we included gcc3 and
stopped defining __FreeBSD__, because the hack in ld to check the rtld
cache wasn't included anymore. This doesn't mean, it was impossible
to link dynamic applications, but we had to add rpath arguments for
all libraries. This is exactly the situation NetBSD has and I'd
happily changed over to that, if it wouldn't have meant loosing
support for almost all build scripts out there, which include the
proper instructions only for NetBSD.

Joerg