libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN


From: Ralf Wildenhues
Subject: Re: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
Date: Mon, 31 Oct 2005 10:13:25 +0100
User-agent: Mutt/1.5.11

Hi Kean,

This time including useful content (sorry!).

* Kean Johnston wrote on Mon, Oct 31, 2005 at 02:02:28AM CET:
>
> OpenServer ships by default with a command line length of 100K, but
> the kernel tunable files are not world-readable, so we cannot detect
> the dynamic value. So, for OSR5, set the value to 100K. If we don't,
> every time libtool is invoked, we get a kernel warning telling us that
> the max command line length table was exceded, and the auto-detect
> mechanism gets a pessimistically low value (it stops at 32K). On
> UnixWare and OpenServer 6, the kernel tunable file *is* world readable
> so we check the real value. If it wasnt tuned by the user the default
> is a lowly 32K.

So I guess we don't want to see the read failure error from grep, since
we deal with it.  This slightly simpler patch should work as well, with
sed being greedy.  OK?

Cheers,
Ralf

> 2005-10-24  Kean Johnston  <address@hidden>
> 
>       * libtool.m4(AC_LIBTOOL_SYS_MAX_CMD_LEN): Set correctly for SCO.

Index: libtool.m4
===================================================================
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.116
diff -u -r1.314.2.116 libtool.m4
--- libtool.m4  31 Oct 2005 08:38:50 -0000      1.314.2.116
+++ libtool.m4  31 Oct 2005 09:09:16 -0000
@@ -738,6 +738,17 @@
       esac
     fi
     ;;
+  sco3.2v5*)
+    lt_cv_sys_max_cmd_len=102400
+    ;;
+  sysv5* | sco5v6* | sysv4.2uw2*)
+    kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null`
+    if test -n "$kargmax"; then
+      lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[       ]]//'`
+    else
+      lt_cv_sys_max_cmd_len=32768
+    fi
+    ;;
   *)
     # 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]