Re: TODO

[Jacob Meuser]

On Wed, Nov 17, 2004 at 08:58:35AM +0100, Ralf Wildenhues wrote:
> * Jacob Meuser wrote on Wed, Nov 17, 2004 at 01:07:20AM CET:
> > 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,
> 
> Can you also be bothered to read
> address@hidden again?
> For archive users, that is message
> http://lists.gnu.org/archive/html/libtool/2004-11/msg00319.html

I think understand the problem there.  deplibs that shouldn't be
specified are picked up from .la files.

> > on Linux, to the linker, all library deplibs do not need to be
> > specified
> 
> ACK.
> 
> > on other systems, to the linker, all library deplibs do need to be
> > specified.
> 
> On some other systems.

yes, of course, not all other systems.

> > libtool is to handle this transparently, just specify the library,
> > and, if needed, libtool will add the deplibs.
> 
> That's what libtool does for every system right now, not only if needed.

yes, I understand that.

> Scotts keybuk-linux-deplibs.patch would change this behavior on linux.

yes, I understand that.

> > am I right so far?
> 
> I think so.
> 
> > 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.
> 
> No breakage.  Developer education:  "There exist other systems with
> linkers that need dependencies explicitly specified."

right, but, as Bob pointed out, there is a new generation of coders
who only use Linux.  why would they care about other systems?  how
would they know what does need to be explicitly specified, and what
shouldn't be specified?

what happens when a deplib that has other deplibs is not a libtool
library?  for example, on BSD systems, the base libraries are not built
with libtool, but on Linux distros, a good part of the base libraries
are built with libtool.

> This education method is not foolproof, however, thus the proposed
> change.

the change to not have libtool not expand deplibs on Linux is not
what I'm arguing about.  telling people to not specify deplibs
is the problem.  it wouldn't be a problem if all libraries on a
system were built with libtool, but that is not the case, especially
on !Linux.

> > how would linux cause the application to break if there was a deplib
> > explicitly specified?
> 
> Read the message above.

wouldn't that be a problem on any system?  since the proposed change
only affects systems that don't need deplibs specified, doesn't the
same problem remain on systems that do need proper deplibs specified,
since libtool will continue to do what it has always done?

so, if this fixes a libtool issue on systems that the libtool
developers use, what is the motivation to fix the exact same issue
for other systems?  is this bug deep in libtool left for users of
systems that don't have linker dependency resolution to figure out?

> Regards,
> Ralf

-- 
<address@hidden>