(no subject)

[Mike Stump]

Could we do something like:

Doing diffs in ltconfig.~1~:
--- ltconfig.~1~        2004-11-12 15:30:40.000000000 -0800
+++ ltconfig    2005-03-25 18:53:56.000000000 -0800
@@ -776,6 +776,11 @@ link_static_flag="$ac_cv_prog_cc_static"
no_builtin_flag="$ac_cv_prog_cc_no_builtin"
can_build_shared="$ac_cv_prog_cc_can_build_shared"

+# Use kernel param if it exists
+lt_cv_sys_max_cmd_len=`sysctl -n kern.argmax 2>/dev/null`
+lt_cv_sys_max_cmd_len=`expr ${lt_cv_sys_max_cmd_len:-0} - $ 
{lt_cv_sys_max_cmd_len:-0} \/ 4`
+if [ $lt_cv_sys_max_cmd_len = 0 ]; then unset lt_cv_sys_max_cmd_len; fi
+
# find the maximum length of command line arguments
echo "$progname:780: finding the maximum length of command line  
arguments" 1>&5
echo $ac_n "finding the maximum length of command line arguments...  
$ac_c" 1>&6
--------------

in libtool?  This speeds up compilation, as, then we can avoid to ld - 
r calls when building libjava on darwin8 for ppc64, these ld -r calls  
are slow (17 minutes)...

The problem is that before we test, and find a computed max of 98K,  
with this patch, the max is then 190k...  and this is enough to do  
the one thing in one step.

We still / 4, to ensure that we have plenty of breathing room on the  
command line.

Things to think about, this is a small dimension change, as before we  
measure the limit directly, the new one doesn't include the current  
environment size, if I understand things correctly.  I don't think  
this is too bad, but, we could do set | wc -c and reduce by that  
amount if it really mattered.