[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: solaris link line length problem == buggy sed
From: |
Robert Boehne |
Subject: |
Re: solaris link line length problem == buggy sed |
Date: |
Wed, 18 Jul 2001 17:50:34 -0500 |
"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],
- Re: solaris link line length problem == buggy sed,
Robert Boehne <=