[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix for Arg list too long
Re: Fix for Arg list too long
31 Jan 2001 17:27:25 -0200
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake)
On Jan 31, 2001, "Boehne, Robert" <address@hidden> wrote:
>> 128Kb, is probably reasonable. The command might be the expr above or
>> a non-built-in echo (using the $0 --fallback-echo comes to mind).
> Alexandre, I'm not familiar with '$0 --fallback-echo', could you
> elaborate on this a bit?
Run `ltconfig --fallback-echo whatever you want'. Similarly for
libtool, and mainline's configure. That's the real echo command we
use as a last resort. Look for --fallback-echo in the beginning of
ltconfig.in to see how it works.
>> Also bear in mind that the invocation of the char-counter itself may
>> fail in case the command line gets too long.
> 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 ltcf-cxx.sh to reduce the divergence from
ltcf-c.sh, 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'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
> #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.
> #2) $reload_cmds will take several objects as input and effectively
> concatenate the files. i.e. linking
> o1.o o2.o o3.o o4.o o5.o
> into a shared library is the same as linking in steps
> $reload_cmds -o newO1.o o1.o o2.o o3.o o4.o
> then linking a shared library with
> newO1.o o5.o
> as input.
Perfect. But we should prefer incremental archiving for the creation
of static libraries, where supported.
> So perhaps a small C program to check argument lengths wouldn't
> be out of order?
Then you'd need a C compiler for the build machine, and you may not
have one. wc, expr or awk should fit the bill, no need to go for a C
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer address@hidden, redhat.com}
CS PhD student at IC-Unicamp address@hidden, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me