[Top][All Lists]

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

RE: Fix for Arg list too long

From: Boehne, Robert
Subject: RE: Fix for Arg list too long
Date: Wed, 31 Jan 2001 18:44:30 -0500

-----Original Message-----
From: Alexandre Oliva [mailto:address@hidden]
Sent: Wednesday, January 31, 2001 1:27 PM
To: Boehne, Robert
Cc: 'address@hidden'
Subject: Re: Fix for Arg list too long

On Jan 31, 2001, "Boehne, Robert" <address@hidden> wrote:

> I have not had this problem with 'wc -c' but I did have it with `expr $cmd :
> ".*"`

You'd also have the problem with `$echo $cmd | wc -c' if echo is not a
shell built-in, so you must take this possibility into account.

> SGI was one system that would not allow me to use $reload_cmds because
> $LD was set to CC.

This is wrong.  LD should be ld, not cc.  That was a kludge we'd used
in the beginning of to reduce the divergence from, but it no longer makes sense.  We should go ahead and use
CC wherever we use LD, and keep LD with a sane value, which is the
name of the linker, not of the compiler.

I definitely agree, I was suprised to see that $reload_cmds did not
work unless it was hacked to use "ld".  I also noticed that the
_expression_ at the top of that sets $LD to MakeC++SharedLib
under AIX has no effect (I guess I should fix that...).

> I'm not sure I understand this, you're saying that some archivers can't
> add several object files to an existing archive properly?

They can.  The problem is that -r is not reversible: as soon as you
merge multiple object files into a single one, the linker will pull
them all from the archive, instead of pulling only the ones that are
actually needed.  That's why I'd rather have object files added
incrementally to static libraries, many at a time, but not by means of

For shared libraries, this doesn't matter, since it's always linked as
a whole.

> #1) $old_archive_cmds will allow users to add objects to an existing
>     archive.  I'm pretty sure this isn't true, but is there a way
>     to add objects to an archive for most supported archivers?

This is true in general.  There will probably be exceptions (Windows,
for one), in which case we won't be able to do incremental adding of
objects, and reloading will be needed.  We'd set some new variable to
tell libtool whether incremental archiving is possible or not.

For archive libraries, I'm not creating reloadable object files,
I'm just executing $old_archive_cmds in several steps, so pulling
individual object files back out won't be a problem.

After some checking I find that `expr "X$arg" : ".*"` fails
when the command list is too long, much like a compiler does.
So if we test for expr failing, that will tell us if the command
line is too long.  The only problem is that using this method
we can't calculate beforehand how many steps we need to link in,
we would have to break the object list in half, try that, then
break that in half it if fails and so on.  How can we do this
without recursive functions?

reply via email to

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