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
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
