[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TODO
From: |
Scott James Remnant |
Subject: |
Re: TODO |
Date: |
Mon, 15 Nov 2004 15:45:10 +0000 |
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.
> 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?
signature.asc
Description: This is a digitally signed message part
- Re: TODO, (continued)
- Re: TODO, Ralf Wildenhues, 2004/11/15
- Re: TODO, Howard Chu, 2004/11/15
- Re: TODO, Gary V. Vaughan, 2004/11/15
- Re: TODO, Gary V. Vaughan, 2004/11/15
- Re: TODO, Ralf Wildenhues, 2004/11/15
- Re: TODO, Gary V. Vaughan, 2004/11/15
- Re: TODO, Scott James Remnant, 2004/11/15
- Re: TODO, Gary V. Vaughan, 2004/11/15
- Re: TODO,
Scott James Remnant <=
- Re: TODO, Jacob Meuser, 2004/11/15
- Re: TODO, Scott James Remnant, 2004/11/16
- Re: TODO, Jacob Meuser, 2004/11/16
- Re: TODO, Ralf Wildenhues, 2004/11/16
- Re: TODO, Jacob Meuser, 2004/11/16
- Re: TODO, Ralf Wildenhues, 2004/11/15
- Re: TODO, Howard Chu, 2004/11/15
- Re: TODO, Ralf Wildenhues, 2004/11/16
- Re: TODO, Bob Friesenhahn, 2004/11/15
- Re: TODO, Daniel Reed, 2004/11/15