Re: Fix for Arg list too long

[Robert Boehne]

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
method
(which of couse, doesn't actually work).  Many compilers have a command
line
switch for giving a list of object files in a text file, SGI, HP and
Tru64
all have this with their native compilers.  I also just can't shake the
notion
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
> LIBTOOL linelen ARG_MAX
> #else
> # if defined NCARGS
> LIBTOOL linelen 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, ltconfig.in seems to be the best
option.

> > 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
definition
of incr_archive_cmds to the ltcf-*.sh files.  I can test quite a few
platforms
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
that
are allowable does not include "wc".  I can't help but use it, or
somthing
else not in the list.  Will this be a problem?  Should we ammend the
list?

Cheers!

Robert

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