Re: TODO

[Jacob Meuser]

On Mon, Nov 15, 2004 at 03:45:10PM +0000, Scott James Remnant wrote:
> On Mon, 2004-11-15 at 15:34 +0000, Gary V. Vaughan wrote:
> 
> > Scott James Remnant wrote:
> > 
> > > I submitted keybuk-linux-deplibs.patch to libtool-patches back in March,
> > > and there was a slight objection from Bob and nobody else joined in to
> > > ok it.
> > 
> > The list was very busy around then, and I was waiting to see the results
> > of you and Bob duking it out ;-)  You didn't answer any of Bob's 
> > questions...
> > 
> I was pretty busy at the time as well, and have been manically busy
> since then with the new job -- only just getting my head above water
> again. 
> 
> >  >Bob Friesenhahn wrote:
> > >> 
> > >> Doesn't this patch cause Linux to be more equal than other operating
> > >> systems, thereby causing free applications to be developed which won't
> > >> work anywhere else?
> > 
> > No, it just shortens the link line on platforms that support that.
> > 
> And, indeed, only does that for shared libraries.
> 
> It should actually promote better support, because you need to remember
> to directly link any library you depend on -- and don't rely on a
> dependency library linking it in for you.
> 
> > >> This solution does not seem to support the case where an actual
> > >> dependency exists but is not registered in the library (because the
> > >> user didn't supply it) so that the dynamic link loader doesn't know
> > >> about it?
> > 
> > Good point.  We really ought to check the library registered
> > dependencies against the .la deplibs and only drop the deplibs
> > common to both, since we know the linker will pick those up.
> > I guess that means looking through the dependency tree of .la
> > files to find matches.
> > 
> It does assume that all library dependencies are registered, yes.  This
> has never been a problem, because we've never found any Libtool-produced
> library that doesn't have all dependencies registered.
> 
> If this isn't the case, and at one time Libtool never registered all of
> the dependencies, we should check for that.  Otherwise I don't see the
> need -- we can assume sanity from our own output.

for a long time, libtool did not handle -pthread properly.
I can point to at least a few .la files on my system that do
not have -pthread or even other required libraries registered.
probably some of that is due to them coming from older packages,
that used older versions of libtool.  some probably are even
using hacked libtools because the version of libtool available at
the time didn't work properly on that system.

the primary objective of libtool is portability, is it not?

> > Also, what do we do about -rpath?  We still need to encode the
> > runtime path to even the dropped deplib directories so that the
> > same library we linked with is picked up at runtime.
> > 
> Libraries have their own RPATH, don't they?
> 
> > >> If libone or libfour contain weak symbols, what happens?
> > 
> > I have no idea!  Scott?
> > 
> They're available to the library that links them.  If the application
> was relying on something down the stack, it was broken anyway and
> should've directly linked libone or libfour itself.
> 
> Scott
> -- 
> Have you ever, ever felt like this?
> Had strange things happen?  Are you going round the twist?

-- 
<address@hidden>