Re: Using getconf to set max_cmd_len
Hi Charles, * Charles Wilson wrote on Sun, Jun 17, 2007 at 10:20:24PM CEST: Committed (to HEAD and branch-1-5). my sendmail hiccuped when trying to send the notification to libtool-commit for branch-1-5, though. I can try to reconstruct that message manually and send it, if you think it's important to do so. (the notification for HEAD went thru without a hitch) No, it's not important. Thanks, Ralf
Re: Using getconf to set max_cmd_len
Ralf Wildenhues wrote: * Charles Wilson wrote on Sun, Jun 17, 2007 at 10:20:24PM CEST: Committed (to HEAD and branch-1-5). my sendmail hiccuped when trying to send the notification to libtool-commit for branch-1-5, though. I can try to reconstruct that message manually and send it, if you think it's important to do so. (the notification for HEAD went thru without a hitch) No, it's not important. Turns out it was a non-issue anyway, as both commit messages did actually get sent. Somehow. -- Chuck
Re: Using getconf to set max_cmd_len
* Charles Wilson wrote on Mon, Jun 18, 2007 at 02:21:30PM CEST: Ralf Wildenhues wrote: * Charles Wilson wrote on Sun, Jun 17, 2007 at 10:20:24PM CEST: Committed (to HEAD and branch-1-5). my sendmail hiccuped when trying to send the notification to libtool-commit for branch-1-5, though. I can try to reconstruct that message manually and send it, if you think it's important to do so. (the notification for HEAD went thru without a hitch) No, it's not important. Turns out it was a non-issue anyway, as both commit messages did actually get sent. Somehow. Ah, yes: it was pending moderation. Other than that, I think they are now generated by the cvs server, no need to generate them on your side. Sorry for having forgotten that last time. Cheers, Ralf
Re: Using getconf to set max_cmd_len
Ralf Wildenhues wrote: * Steve Ellcey wrote on Thu, May 31, 2007 at 12:58:37AM CEST: 2007-05-30 Steve Ellcey [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): Try using getconf to set lt_cv_sys_max_cmd_len. [...] +lt_cv_sys_max_cmd_len=`getconf ARG_MAX 2 /dev/null` The patch is all good (thanks!) except someone please put `getconf ARG_MAX' in a subshell so that if it does not exist, the shell error output is redirected as well (both branches). OK to apply (both branches)? 2007-06-17 Charles Wilson ... Ralf Wildenhues ... * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): ensure error is redirected even when getconf does not exist. -- Chuck ? .signature Index: libltdl/m4/libtool.m4 === RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.105 diff -u -r1.105 libtool.m4 --- libltdl/m4/libtool.m4 4 Jun 2007 03:01:11 - 1.105 +++ libltdl/m4/libtool.m4 17 Jun 2007 18:23:24 - @@ -1437,7 +1437,7 @@ fi ;; *) -lt_cv_sys_max_cmd_len=`getconf ARG_MAX 2 /dev/null` +lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2 /dev/null` if test -n $lt_cv_sys_max_cmd_len; then lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4` lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3` Index: libtool.m4 === RCS file: /sources/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.179 diff -u -r1.314.2.179 libtool.m4 --- libtool.m4 4 Jun 2007 03:28:27 - 1.314.2.179 +++ libtool.m4 17 Jun 2007 18:25:33 - @@ -794,7 +794,7 @@ fi ;; *) -lt_cv_sys_max_cmd_len=`getconf ARG_MAX 2 /dev/null` +lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2 /dev/null` if test -n $lt_cv_sys_max_cmd_len; then lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4` lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
Re: Using getconf to set max_cmd_len
On Sun, 2007-06-17 at 20:39 +0200, Ralf Wildenhues wrote: * Charles Wilson wrote on Sun, Jun 17, 2007 at 08:32:33PM CEST: OK to apply (both branches)? Of course. Thanks. And no need for my name in the ChangeLog entry. Cheers, Ralf 2007-06-17 Charles Wilson ... Ralf Wildenhues ... * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): ensure error is redirected even when getconf does not exist. I noticed that when I tried this with 'getconf' changed to some non-existing utility I got errors from expr. Turns out that we need to quote the string for test -n. Applied to HEAD and branch-1-5. Peter 2007-06-17 Peter O'Gorman [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): add quotes to the test -n. Index: libltdl/m4/libtool.m4 === RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.106 diff -u -r1.106 libtool.m4 --- libltdl/m4/libtool.m4 17 Jun 2007 20:16:03 - 1.106 +++ libltdl/m4/libtool.m4 18 Jun 2007 00:42:17 - @@ -1438,7 +1438,7 @@ ;; *) lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2 /dev/null` -if test -n $lt_cv_sys_max_cmd_len; then +if test -n $lt_cv_sys_max_cmd_len; then lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4` lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3` else
Re: Using getconf to set max_cmd_len
* Steve Ellcey wrote on Thu, May 31, 2007 at 12:58:37AM CEST: 2007-05-30 Steve Ellcey [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): Try using getconf to set lt_cv_sys_max_cmd_len. [...] +lt_cv_sys_max_cmd_len=`getconf ARG_MAX 2 /dev/null` The patch is all good (thanks!) except someone please put `getconf ARG_MAX' in a subshell so that if it does not exist, the shell error output is redirected as well (both branches). Thanks, Ralf
Re: Using getconf to set max_cmd_len
On Thu, 2007-05-31 at 08:08 +0200, Paolo Bonzini wrote: Steve Ellcey wrote: While integrating a newer libtool into GCC, an issue arose with what value libtool was setting max_cmd_len to. This patch uses 'getconf ARG_MAX' to set lt_cv_sys_max_cmd_len instead of going through a loop to try and divine the right value, this should give a more accurate value and should be faster too. getconf is a Posix command that most platforms have and we drop into the old behaviour if it doesn't exist. I originally thought about putting the getconf call before the case statement (thus skipping the special case handling if getconf exists), but then I thought it would be better to put the getconf usage into the generic case only so that people could still have special case targets if they wanted to avoid using getconf. If the special case targets want to use getconf they can just delete their entry from the case statement and fall into the generic case. This patch is okay for gcc and src also before Peter puts it in libtool. I applied it to HEAD and branch-1-5 on the theory that if it is broken somewhere then we'll hear about it and can add it to the case statement above. The time saved in configure is surely worth it. By the way, at least osf5 'getconf ARG_MAX' returns a result that is not at all related to the real arg max (but osf is already special cased, so...) Peter
Re: Using getconf to set max_cmd_len
Steve Ellcey wrote: While integrating a newer libtool into GCC, an issue arose with what value libtool was setting max_cmd_len to. This patch uses 'getconf ARG_MAX' to set lt_cv_sys_max_cmd_len instead of going through a loop to try and divine the right value, this should give a more accurate value and should be faster too. getconf is a Posix command that most platforms have and we drop into the old behaviour if it doesn't exist. I originally thought about putting the getconf call before the case statement (thus skipping the special case handling if getconf exists), but then I thought it would be better to put the getconf usage into the generic case only so that people could still have special case targets if they wanted to avoid using getconf. If the special case targets want to use getconf they can just delete their entry from the case statement and fall into the generic case. This patch is okay for gcc and src also before Peter puts it in libtool. Paolo
Using getconf to set max_cmd_len
While integrating a newer libtool into GCC, an issue arose with what
value libtool was setting max_cmd_len to. This patch uses 'getconf
ARG_MAX' to set lt_cv_sys_max_cmd_len instead of going through a loop to
try and divine the right value, this should give a more accurate value
and should be faster too. getconf is a Posix command that most
platforms have and we drop into the old behaviour if it doesn't exist.
I originally thought about putting the getconf call before the case
statement (thus skipping the special case handling if getconf exists),
but then I thought it would be better to put the getconf usage into the
generic case only so that people could still have special case targets
if they wanted to avoid using getconf. If the special case targets want
to use getconf they can just delete their entry from the case statement
and fall into the generic case.
Peter O'Gorman recommended using 3/4 of the value that getconf returned,
so that is what I did.
I wasn't able to test this with the libtool test suite, I couldn't do a
bootstrap and when I just did a configure;make;make check with the
daily snapshot it didn't look like the new code was being used.
I did put the patch in my GCC tree and reconfigure and use it that way
and verified that it worked in that context. Most of the change is just
indentation differences, there is really only a few new lines.
Steve Ellcey
[EMAIL PROTECTED]
2007-05-30 Steve Ellcey [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): Try using getconf
to set lt_cv_sys_max_cmd_len.
Index: libtool.m4
===
RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.103
diff -u -p -r1.103 libtool.m4
--- libtool.m4 28 May 2007 07:03:25 - 1.103
+++ libtool.m4 30 May 2007 22:15:56 -
@@ -1437,29 +1437,35 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [d
fi
;;
*)
-# Make teststring a little bigger before we do anything with it.
-# a 1K string should be a reasonable start.
-for i in 1 2 3 4 5 6 7 8 ; do
- teststring=$teststring$teststring
-done
-SHELL=${SHELL-${CONFIG_SHELL-/bin/sh}}
-# 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.
-while { test X`$SHELL [$]0 --fallback-echo X$teststring$teststring
2/dev/null` \
- = XX$teststring$teststring; } /dev/null 21
- test $i != 17 # 1/2 MB should be enough
-do
- i=`expr $i + 1`
- teststring=$teststring$teststring
-done
-# Only check the string length outside the loop.
-lt_cv_sys_max_cmd_len=`expr X$teststring : .* 21`
-teststring=
-# Add a significant safety factor because C++ compilers can tack on massive
-# amounts of additional arguments before passing them to the linker.
-# It appears as though 1/2 is a usable value.
-lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 2`
+lt_cv_sys_max_cmd_len=`getconf ARG_MAX 2 /dev/null`
+if test -n $lt_cv_sys_max_cmd_len; then
+ lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
+ lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
+else
+ # Make teststring a little bigger before we do anything with it.
+ # a 1K string should be a reasonable start.
+ for i in 1 2 3 4 5 6 7 8 ; do
+teststring=$teststring$teststring
+ done
+ SHELL=${SHELL-${CONFIG_SHELL-/bin/sh}}
+ # 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.
+ while { test X`$SHELL [$]0 --fallback-echo X$teststring$teststring
2/dev/null` \
+= XX$teststring$teststring; } /dev/null 21
+ test $i != 17 # 1/2 MB should be enough
+ do
+i=`expr $i + 1`
+teststring=$teststring$teststring
+ done
+ # Only check the string length outside the loop.
+ lt_cv_sys_max_cmd_len=`expr X$teststring : .* 21`
+ teststring=
+ # Add a significant safety factor because C++ compilers can tack on
+ # massive amounts of additional arguments before passing them to the
+ # linker. It appears as though 1/2 is a usable value.
+ lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 2`
+fi
;;
esac
])
Re: Using getconf to set max_cmd_len
On Wed, 2007-05-30 at 15:58 -0700, Steve Ellcey wrote: While integrating a newer libtool into GCC, an issue arose with what value libtool was setting max_cmd_len to. This patch uses 'getconf ARG_MAX' to set lt_cv_sys_max_cmd_len instead of going through a loop to try and divine the right value, this should give a more accurate value and should be faster too. getconf is a Posix command that most platforms have and we drop into the old behaviour if it doesn't exist. I originally thought about putting the getconf call before the case statement (thus skipping the special case handling if getconf exists), but then I thought it would be better to put the getconf usage into the generic case only so that people could still have special case targets if they wanted to avoid using getconf. If the special case targets want to use getconf they can just delete their entry from the case statement and fall into the generic case. Peter O'Gorman recommended using 3/4 of the value that getconf returned, so that is what I did. I wasn't able to test this with the libtool test suite, I couldn't do a bootstrap and when I just did a configure;make;make check with the daily snapshot it didn't look like the new code was being used. I did put the patch in my GCC tree and reconfigure and use it that way and verified that it worked in that context. Most of the change is just indentation differences, there is really only a few new lines. Looks good to me, I'll test it tonight and apply it to HEAD and branch-1-5. I'll let you know if anything crops up that requires making changes. Thank you! Peter
