[Top][All Lists]

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

Re: Fix for Arg list too long

From: Robert Boehne
Subject: Re: Fix for Arg list too long
Date: Tue, 12 Dec 2000 15:37:55 -0600

Alexandre Oliva wrote:
> On Dec 12, 2000, Robert Boehne <address@hidden> wrote:
> > Using the multi-language-branch as a starting point, I have a working
> > "libtool" script that incrementally links libraries to prevent running
> > into limits of the shell.
> Cool!
> > I have defined two new shell variables in libtool,
> > ${incr_archive_cmds} and ${old_incr_archive_cmds}, which are used
> > instead of ${archive_cmds}/${old_archive_cmds} when ${max_cmd_len}
> > is less than the length of the expanded
> > "${archive_cmds}/${old_archive_cmds}".
> I can see the point of old_incr_archive_cmds, given that
> old_archive_cmds can be pretty much anything, and you can't count on
> being able to incrementally add object files to it, but the good thing
> is that old_archive_cmds is only overridden on Cygwin and Mingw.
> However, incr_archive_cmds doesn't seem very useful to me.  It would
> seem to me that it would be easier to arrange for libtool to know how
> to use reload_flag to link multiple object files into a single one,
> and iterate until the command line is short enough.

Right now, $incr_archive_cmds will first create an archive file one .o
at a time,
then link a shared object with the archive file in place of $libobjs.
This works, _but_ it is an order of magnitude slower than the direct
(which of couse, doesn't actually work).  Many compilers have a command
switch for giving a list of object files in a text file, SGI, HP and
all have this with their native compilers.  I also just can't shake the
that some platforms won't let you create shared objects from archives.
(of couse I could be wrong)

> But I like the idea of using preprocessor symbols.  How about
> preprocessing a program with the same #includes you use, but ending
> with:
> #if defined ARG_MAX
> #else
> # if defined NCARGS
> # endif
> #endif
> Then you grep the preprocessed file for '^LIBTOOL linelen  *[0-9]* *' and
> extract the constant with sed.  If there's no such constant, we might
> play with binary searching the length by running, say, `ls'.  Or just
> go with a fixed, reasonable number, that can then be increased on a
> per-platform basis.

Ah, yes, I hadn't thought about that, I'll incorporate your suggestion.
Sill I wonder what file to put it in, seems to be the best

> > In my current implementation, the old method of linking is used unless
> > ${incr_archive_cmds} is defined AND the command is too long for the
> > shell.
> What if the command line is too long and incr_archive_cmds isn't
> defined?

In this case there is some work to do, someone needs to add the
of incr_archive_cmds to the ltcf-*.sh files.  I can test quite a few
here (~7) , the rest will be left as an exercise for the reader.  ;)

Also, in reading the GNU Coding Standards, the list of unix commands
are allowable does not include "wc".  I can't help but use it, or
else not in the list.  Will this be a problem?  Should we ammend the



Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  address@hidden

reply via email to

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