Re: check for max cmd line length

[Gary V . Vaughan]

On Friday 29 June 2001 12:08 am, Robert Boehne wrote:
> "Gary V. Vaughan" wrote:
> > On Monday 25 June 2001  5:20 pm, Tim Van Holder wrote:
> > > > > Please don't check for this on the Hurd, (*-gnu*), but just set it
> > > > > to any maximum value you need.
> > > >
> > > > Hmm.. I can't decide if this is good news or not. ;)  I think what
> > > > needs to be done is to add some mechanism for telling Libtool
> > > > that there is no maximum.  That would involve a check for Hurd
> > > > and setting a flag in configury, then in the libtool script
> > > > checks that skip the piecewise linking if the flag is set.
> > >
> > > That, or you could just set some high default in
> > > AC_LIBTOOL_SYS_MAX_CMD_LEN (say, 256K, as it seems fairly unlikely that
> > > would be hit often) the same way a default is now set for DJGPP (where
> > > the test would otherwise blow up the system).
> >
> > I deliberately fiddled Tim's patch for DJGPP with the hurd problem in
> > mind... I was just waiting to find this thread again while working
> > through the couple of hundred I have marked for attention before 1.4b is
> > released.
> >
> > However, I don't want to blindly patch libtool if it a) masks a bug
> > elsewhere in libtool, b) masks a bug in the hurd.
> >
> > Marcus, making this change in libtool is now a no-brainer, but we'll
> > await your verdict on whether this is the the Right Thing To Do, or
> > whether it is a bug elsewhere that you are seeing before we do anything
> > else.
> >
> > Cheers,
> >         Gary.
>
> Gary:
>
> I considered writing this in when I did the piecewise linking code, but
> I
> didn't think any systems would not have such limits.  I agree it's a
> no-brainer,
> which is why I'm so qualified to do it.  ;)  I don't think it is risky,
> and IMHO it just covers our bases, so it's a Good Thing (TM).

Fair enough.  If Marcus doesn't have a chance to get back to us before the 
weekend, then by all means commit a change to HEAD.  One thing to watch out 
for is not to accidentally match ``linux-gnu'' when matching against ``gnu'' 
(i.e. hurd) in a $host_os case.

I'm planning to release 1.4b at the weekend to elicit some feedback on how 
well the MLB merge has worked out... I guess I should don my asbestos suit 
just in case =)O|

Do you have any thoughts on the unquoted-variables-in-a-test problem that 
several people reported against the half merged MLB?  I am in two minds:  the 
variables that were causing syntax errors should never be unset, and it will 
be difficult to spot these errors if we hide them in quotes; OR dying with a 
syntax error due to an unforseen combination at configure time is sucky, so 
we should limp on with a best guess.  The first option feels like the right 
thing, and I hope that the full merge will have fixed the reported problems, 
but I'm open to persuasion.

Cheers,
        Gary.
-- 
  ())_.  Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/   Research Scientist  http://www.oranda.demon.co.uk        ,_())____
  / )=   GNU Hacker          http://www.gnu.org/software/libtool   \'      `&
`(_~)_   Tech' Author        http://sources.redhat.com/autobook    =`---d__/