, Todd Vierling <tv@wasabisystems.com>
From: Nick Hudson <skrll@netbsd.org>
List: tech-toolchain
Date: 03/14/2002 08:29:26
On Wednesday 13 March 2002 9:45 pm, Johnny Lam wrote:
> On Wed, Mar 13, 2002 at 10:53:12AM -0500, Todd Vierling wrote:
> > On Tue, 12 Mar 2002, Johnny Lam wrote:
[...]
> > FROM MEMORY ONLY, may be incorrect: The a.out linker, in case (a), will
> > encode a major number and minimum minor number for use by the runtime
> > linker. However, if a full filename as in case (b) is given with
> > .major.minor, only that specific library pathname will be usable -- any
> > library with an incremented minor number will not link.
>
> Given how pkgsrc works, that would be bad. I'll try some tests on the
> mac68k, but will those results be representative for all NetBSD/a.out
> platforms?
Johnny, why are you concerned about a.out? The problem you described with
libtool is only relevant for ELF as it doesn't have hardcode_direct=yes. The
reason is that the ELF linker doesn't doesn't follow the semantics described
below.
> > There's another possible difference, but you'd need to test it, as I've
> > never checked NetBSD's a.out linker for this: Some linkers will encode
> > the full path provided in case (b) into the dependent, rather than just a
> > libname, resulting in a binary that has an absolute path (which would be
> > bad for multiple libtooled libraries built together in one tree). In such
> > cases, rpath and LD_LIBRARY_PATH are unusable for finding the shared
> > object if it moves.
Nick