libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TODO


From: Jacob Meuser
Subject: Re: TODO
Date: Tue, 16 Nov 2004 16:07:20 -0800
User-agent: Mutt/1.4.2i

On Tue, Nov 16, 2004 at 11:00:34PM +0000, Scott James Remnant wrote:
> On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote:
> 
> > On Tue, Nov 16, 2004 at 03:02:55PM +0000, Scott James Remnant wrote:
> > > Actually, I'd say the opposite is true ... the LONGER link line,
> > > produced by the current Libtool, is what allows people to get away with
> > > this because Libtool puts more stuff into the link line.
> > > 
> > > A shorter, more concise, link line actually forces people to make sure
> > > they *do* link anything they require themselves, rather than relying on
> > > Libtool to do the right thing for them.
> > 
> > but where does the problem show up?  on !Linux, because Linux will
> > "do the right thing".
> > 
> No, on Linux ... because Linux does the right thing and causes the
> applications to break; whereas Libtool does the wrong thing and links
> the application directly with half the libraries on the system.

from my understanding, correct me if I'm wrong,

on Linux, to the linker, all library deplibs do not need to be
specified

on other systems, to the linker, all library deplibs do need to be
specified.

libtool is to handle this transparently, just specify the library,
and, if needed, libtool will add the deplibs.

am I right so far?

so when libtool fails to complete the deplibs (I still haven't seen
any explanation for what happens when one of the deplibs is a
non-libtool library), where is there breakage?  not on Linux, because
it doesn't need the deplibs anyway.

how would linux cause the application to break if there was a deplib
explicitly specified?

-- 
<address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]