libtool
[Top][All Lists]
Advanced

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

Re: Fix for Arg list too long


From: Alexandre Oliva
Subject: Re: Fix for Arg list too long
Date: 31 Jan 2001 06:39:45 -0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake)

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

> #1)  I have to check for the existence of 'wc -c' to check the
> command line length.

I'd rather not rely upon fixed limits.  I was thinking about doing it
dynamically.  For example, as the command line grows, test that you
can still $echo it before committing to the addition of a new
argument.  But I realize this may be very hard to do right.

If you really want to use something like `wc -c', make sure you set up
portable fallbacks, such as expr "X$val" : ".*" and awk's length().

Instead of looking for fixed limits in header files, we might just try
larger and larger commands until we bump onto a limit.  Starting at
128 and doubling on each iteration until it fails or gets to, say,
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).

Also bear in mind that the invocation of the char-counter itself may
fail in case the command line gets too long.

> #2)  I am checking the system header files to find the maximum command
> line length.  Currently I have this in ltconfig.in, but it really
> only needs to be run once for each platform, not each tag.  Where should
> it go?

ltconfig is indeed the right place for it (in MLB until we move it
into libtool.m4, as Gary did in mainline).  So far, we don't have
infrastructure to do the test only for the main configuration; maybe
after moving to libtool.m4 we should; that will make it much easier.

> #3) $LD is set to $CXX in most cases for C++ compilers

My opinion is that this is wrong.  We should just bite the bullet and
use $CXX all over, leaving $LD with the correct value.

> A previous design linked objects one at a time

We should probably keep some version of the previous design, at least
for static libraries.  It's not good to link multiple objects together
in case they're going to be stored into a static library, because
linkers often pull whole object files out of static libraries.  We'd
better add them incrementally (but we can do it many at a time).  We
should probably have some configuration flag to indicate that
incremental old_archiving is not possible, and fallback to relinking
in this case.

-- 
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



reply via email to

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