On Tue, Mar 19, 2002 at 08:15:23AM +0000, Nick Hudson wrote:
> On Monday 18 March 2002 9:42 pm, Johnny Lam wrote:
> > I'm going to try to reformulate with a simpler example to try to make
> > clearer what I perceive to be the problem.  The following example is
> > distilled from something I received in private email regarding problems
> > with packages having hidden dependencies on devel/gettext-lib.
> 
> OK. There are two problems here.
> 
> The solution to the first problem, I still believe, is as simple as 
> introducing -L/buildlink/lib before the libbase.la option to libtool. 
> Although I'm not completely sure that won't introduce some unwanted side 
> effects.

Yes, I'm sure that would certainly work.  I decided to try my change
instead, since I thought it would lead to fewer modifications to package
Makefiles down the road.  I especially fear large packages that fully use
automake and libtool as they might need an unwieldy number of patches.

> The second problem is much harder as it affects all a.out linking for 
> libraries with uninstalled dependencies. That is, anything that gets relinked 
> by libtool. In this case hardcode_direct=yes is probably the wrong for a.out, 
> but that opens a whole can of worms. Let me get back to you.

Yes, on a.out, hardcode_direct=yes only indirectly describes what is
happening.  Linking against DIR/libNAME.so does hardcode DIR into a
resulting library or binary, but only because the whole library name is
hardcoded, and it leads to linking the libraries in such a way that updates
are impossible.  However, I see what you mean about a "can of worms" as
simply setting hardcode_direct=no doesn't work since it's simply not true,
and making this wrong assumption breaks libtool on a.out platforms.

Ugh.  I'll think about it some more, too.  I wonder if other OSes with
a.out linkage (SunOS? OpenBSD?) have this same problem.  Has libtool been
broken for so long?

	Cheers,

	-- Johnny Lam <jlam@jgrind.org>