Re: solaris link line length problem == buggy sed

[Robert Boehne]

"Gary V. Vaughan" wrote:
> 
> On Wednesday 18 July 2001 12:33 am, Robert Boehne wrote:
> > Alex Hornby wrote:
> > > My earlier link line truncation problem on solaris was not due to
> > > command line length restrictions (getconf reports a healthy 109kb for
> > > ARG_MAX).
> > >
> > > Solaris 2.6 /usr/bin/sed, as used by libtool during the link, has
> > > problems with "long" lines of > 3999 characters, truncating them as it
> > > sees fit.
> > >
> > > By putting GNU sed ahead of solaris sed on my PATH the build succeeds.
> > >
> > > Should libtool work around such broken sed's during the build phase,
> > > and would patches be considered that did this?
> > >
> > > Regards,
> > > Alex.
> >
> > Ok, I'm trying to write a macro for libtool.m4 that will check for
> > bugs such as this one in sed.  However, if I create a file inline
> > with 8202 characters on one line, Linux bash segfaults!
> > It does work under IRIX and Solaris, so my approach seems OK.
> > Here is what it basically does:
> >
> >   cat > conftest.$ac_ext <<EOF
> > XXXXXXXXXX<SNIP 8200 'X' characters>
> > EOF
> >   sed 's/Y/Z/g' conftest.$ac_ext > conftest.out
> >   lt_cv_buggy_sed="yes"
> >   cmp conftest.$ac_ext conftest.out >/dev/null && lt_cv_buggy_sed="no"
> > 2>&1
> >   ls -al conftest.$ac_ext conftest.out
> >   cat conftest.$ac_ext
> > fi
> >
> > Since bash 1.14.7 under Linux (Redhat 6.2) seems to have a
> > problem with such a long inline file, is there a way to
> > concatenate a character or characters into a file without
> > adding newlines?
> 
> The easiest way to do it without tripping over echo non-portabilities is:
> 
>   echo | tr '\010' X >> file
> 
> Ofcourse tr has some issues of its own, so you might prefer:
> 
>   echo | awk '{ printf "X"; }' >> file
> 
> But then you have to find a suitable awk binary in your PATH, so maybe
> testing which of the following leaves no droppings and use that:
> 
>   echo -n X
>   echo 'X\c'
>   echo -e 'X\c'
> 
> Which takes us back to the start.  Go round a few times, and get off at your
> favourite stop =)O|
> 
> > Granted, I can simply skip this if GNU sed is found, but
> > I'm sure it will come up again on some other sed/shell
> > combination.
> 
> This is really an autoconf macro, since it has applicability beyond what
> libtool needs...
> 
> Cheers,
>         Gary.

OK,
  I've got somthing that works, and a lack of time for adding features
to it.
This new macro in libtool.m4 checks the user's sed and reports a warning
if it truncates output.  It works properly on the three systems I've
tested
it on and there are no test regressions on my Linux box.
  What wasn't implemented:
#1 Checking various sed programs for ones that
    may work, i.e. gsed, /usr/xpg4/bin/sed.

#2 Setting $SED and propogating it to the libtool script.

#3 Thinking about a macro for general use.

This macro serves a needed purpose as is, so I'd like to check it in.
As for the shortcomings above, anyone want to help?
I just can't spare the time right now.

ChangeLog entry:
2001-07-18  Robert Boehne  <address@hidden>

        * libtool.m4 (AC_LIBTOOL_SED_TRUNCATES): New macro that
        determines whether or not the sed program being used by
        libtool truncates its output up to 10010 characters on
        a single line.


-- 
Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  address@hidden

2001-07-18  Robert Boehne  <address@hidden>

        * libtool.m4 (AC_LIBTOOL_SED_TRUNCATES): New macro that
        determines whether or not the sed program being used by
        libtool truncates its output up to 10010 characters on
        a single line.
 
Index: libtool.m4
===================================================================
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.195
diff -u -r1.195 libtool.m4
--- libtool.m4  2001/07/16 19:11:34     1.195
+++ libtool.m4  2001/07/18 22:37:47
@@ -537,6 +537,48 @@
 ])# AC_LIBTOOL_LINKER_OPTION
 
 
+# AC_LIBTOOL_SED_TRUNCATE
+# --------------------------
+AC_DEFUN([AC_LIBTOOL_SED_TRUNCATE],
+[# Check the sed program to see if it truncates its output
+AC_MSG_CHECKING([if sed truncates output lines])
+AC_CACHE_VAL([lt_cv_buggy_sed], [dnl
+if sed -V 2>&1 | egrep 'GNU' > /dev/null; then
+  # We are using GNU sed, which doesn't truncate.
+  lt_cv_buggy_sed="no"
+else
+  cat > conftest.$ac_ext <<EOF
+[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]
+EOF
+  i=0
+  # The number 415 gives us 10,010 characters, probably
+  # enough to catch yet unknown seds that have this problem.
+  while test $i != 415
+  do
+    i=`expr $i + 1`
+    echo | awk '{ printf "XXXXXXXXXXXXXXXXXXXXXXXX"; }' >> conftest.$ac_ext
+  done
+  sed 's/Y/Z/' conftest.$ac_ext > conftest.out
+  lt_cv_buggy_sed="yes"
+  ( cmp conftest.$ac_ext conftest.out 2>&1 && lt_cv_buggy_sed="no" ) >/dev/null
+  rm -f conftest.$ac_ext conftest.out
+fi
+])
+AC_MSG_RESULT($lt_cv_buggy_sed)
+if test $lt_cv_buggy_sed != "no" ; then
+       cat <<EOF 1>&2
+
+*** Warning: the sed program libtool is configured to use, sed,
+*** truncates its output.  The result is that libtool may be unable
+*** to create large libraries without run-time errors.
+*** Configure libtool to use GNU sed, or an alternative sed program
+*** that does not truncate its output.
+
+EOF
+fi
+])# AC_LIBTOOL_SED_TRUNCATE
+
+
 # AC_LIBTOOL_SYS_MAX_CMD_LEN
 # --------------------------
 AC_DEFUN([AC_LIBTOOL_SYS_MAX_CMD_LEN],