Re: Fix for Arg list too long

[Alexandre Oliva]

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.

> Since ${max_cmd_len} is not compiler-dependent, where should it be
> defined?

Good question.  I wish I knew the answer :-)

> The value can be determined with a short C program such as this:

You can't depend on being able to run a C program.  Think of
cross-compilation.

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.  

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

> I would like a bit of guidance since I seem to be hacking at the core
> here.

Indeed, you are.  Sorry for not being more responsible, I've been far
too busy for the past few weeks :-(

> RMS suggested that it may be better to have libtool read commands from
> a file, could one of the maintainers comment on that?

This is definitely a good idea, but it can only work after what you're
doing is implemented.  One issue is that of preventing libtool from
issuing command lines that are too long; the other is that of letting
our users link as many object files as they want with libtool, despite
command-line length limits that might arise in the invocation of
libtool itself.  You've been working on the former, but, in many
cases, people with long lists of object files to link into a library
will need the latter too.

I suggest doing one thing at a time.


Thank you *so* much for taking this over this task :-)

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