[PATCH] lower cap on max_cmd_len to fix hppa2.0w-hp-hpux11.00

[Michael Elizabeth Chastain]

Here is a short patch to libtool.m4 to fix a build problem with host
hppa2.0w-hp-hpux11.00.  I'm motivated to do this because the "ltconfig"
file in gcc 3.0 does not work on native hppa2.0w-hp-hpux11.00; but the
problem happens when I build libtool on its own.

With today's CVS HEAD version of libtool, I get this error:

  checking the maximum length of command line arguments... 
/horton/chastain/baseline/libtool-cvs/configure[3804]: There is not enough 
memory available now.

I thought about fixing this the same way as djgpp (picking a value).
But that's bad because I can't guarantee any particular value on every
hppa*-hp-hpux11.* system.  So I fixed it by lowering the top limit
from 1 MB to 512 KB.  Irony: 512 kilobytes ought to be enough for anybody,
right?

I tested this patch by running before-and-after build-and-test on several
different native systems.  I prepared the source directories from a
clean copy of the CVS files.  Then I either left the files alone or
applied the patch.  Then I ran "bootstrap", and then I did some "touch"
commands because some of the systems I use have wanky clocks, and then
I did a conventional make / make check / make install.

My baseline tools (on every platform) are:

  gnu make 3.79.1
  binutils 2.11.2
  gcc 3.0
  autoconf 2.50
  automake 1.4-p4

Here is a table showing max_cmd_len and test fails for each platform that
I tested.  Both max_cmd_len and the test results are identical before
and after, on all machines, except for native hppa2.0w-hp-hpux11.00.

                                      max_cmd_len   tests failed

  native hppa1.1-hp-hpux10.20               12289          23/74
  native hppa2.0w-hp-hpux11.00 (before)   -abort-          **/**
  native hppa2.0w-hp-hpux11.00 (after)     393217          23/74
  native i686-pc-linux-gnu (rhl 6.0)        49153          26/84
  native i686-pc-linux-gnu (rhl 6.1)        49153          26/84
  native i686-pc-linux-gnu (rhl 6.2)        49153          26/84
  native i686-pc-linux-gnu (rhl 7)          49153          26/84
  native sparc-sun-solaris2.5.1              1537          34/84
  native sparc-sun-solaris2.6              393217          26/84
  native sparc-sun-solaris2.7              393217          26/84
  native sparc-sun-solaris2.8              393217          26/84

I did all of my work with the HEAD branch.  After the patch is applied to
HEAD, I can also test it and submit it for multi-language-branch,
if the maintainers wish.

Can a libtool maintainer apply this to HEAD?

Michael Elizabeth Chastain
<address@hidden>
"love without fear"

===

2001-07-01  Michael Chastain  <address@hidden>

        * libtool.m4: reduce max_cmd_len cap from 1 MB to 512 KB.

diff -u -r ORIG-libtool-cvs/libtool.m4 libtool-cvs-2/libtool.m4
--- ORIG-libtool-cvs/libtool.m4 Fri Jun 29 19:39:18 2001
+++ libtool-cvs/libtool.m4      Sun Jul  1 18:40:32 2001
@@ -556,11 +556,14 @@
     # If test is not a shell built-in, we'll probably end up computing a
     # maximum length that is only half of the actual maximum length, but
     # we can't tell.
+    #
+    # Stop at 512K, because probing any further causes problems on
+    # host hppa2.0w-hp-hpux11.00.
     while test "X"`$CONFIG_SHELL [$]0 --fallback-echo "X$testring" 
2>/dev/null` \
                = "XX$testring" &&
             new_result=`expr "X$testring" : ".*" 2>&1` &&
             lt_cv_sys_max_cmd_len=$new_result &&
-            test $i != 18 # 1 MB should be enough
+            test $i != 17 # 512 KB should be enough
     do
       i=`expr $i + 1`
       testring=$testring$testring