Re: Problem with Libtool 2.2.x's AC_PROG_SED on Solaris

[Daniel Richard G.]

Hi Ralf,

On Sat, 2008 Oct 25 10:03:15 +0200, Ralf Wildenhues wrote:
> 
> Which Solaris version, and which Autoconf version do you use?

This problem is observable on two Solaris 8 systems (one on x86, one on 
SPARC64), and I'm using autoconf 2.61.

The bug does not occur on Solaris 10. There, /usr/bin/sed appears to handle 
long lines correctly. Curiously, the same build error does not seem to crop 
up on an older SunOS 5.6 system I have here, though I won't know for sure 
until it finishes running through the whole build again in a few days. 
(It's a slowpoke!)

I've put together a couple of tests that may help reveal the limitations of 
all these sed implementations:

Test 1:
        ( gnu-seq 1 10000 | tr '\n' ' ' ; echo end ) \
        | $SED 's/ 1000 / THOUSAND /g' \
        > output

Test 2:
        ( gnu-seq 1 10000 | tr '\n' ' ' ; echo end ) \
        | $SED 's/ 10000 / TEN-THOUSAND /g' \
        > output

(The salient difference is that these perform replacement before/after the 
4000-byte mark, which appears to be significant for most Solaris seds. 
Also, I use gnu-seq as Solaris does not ship with an seq(1) command.)

SunOS 5.6 (SPARC):
        Test 1:
                /usr/bin/sed: "Output line too long."
                /usr/ucb/sed: "Output line too long."
                /usr/xpg4/bin/sed: OK
        Test 2:
                /usr/bin/sed: Silent truncation at 4000 bytes
                /usr/ucb/sed: Silent truncation at 4000 bytes
                /usr/xpg4/bin/sed: Bus error

Solaris 8 (x86 and SPARC64 alike):
        Test 1:
                /usr/bin/sed: "Output line too long."
                /usr/ucb/sed: "Output line too long."
                /usr/xpg4/bin/sed: OK
        Test 2:
                /usr/bin/sed: Silent truncation at 4000 bytes
                /usr/ucb/sed: Silent truncation at 4000 bytes
                /usr/xpg4/bin/sed: Segmentation fault

Solaris 10 (AMD64):
        Test 1:
                /usr/bin/sed: OK
                /usr/ucb/sed: "Output line too long."
                /usr/xpg4/bin/sed: OK
        Test 2:
                /usr/bin/sed: OK (about damn time!)
                /usr/ucb/sed: Silent truncation at 4000 bytes
                /usr/xpg4/bin/sed: Segmentation fault

Looks like you have your work cut out for you :(

> AC_PROG_SED has been moved into Autoconf proper, and Libtool only has a
> fall-back implementation now.  Since then, the macro version in Autoconf
> has accumulated several changes, among them:
> 
>   2006-05-21  Paul Eggert  <address@hidden>
>           and Ralf Wildenhues  <address@hidden>
> 
>           * lib/autoconf/programs.m4 (AC_PROG_SED): Catch script length
>           limits in Solaris 8 /usr/ucb/sed by testing a long script.
> 
>   2005-02-04  Paul Eggert  <address@hidden>
> 
>           * lib/autoconf/programs.m4 (AC_PROG_SED): Don't look in
>           /usr/xpg4/bin since that sed dumps core (at least on Solaris 8).
> 
> 
> as well as some refactorization.  The second of those changes looks
> suspicious.
> 
> IIRC then it was deemed not stable to test for the core dump mentioned
> above.  We could however add testing to ensure that the long input line
> munging doesn't happen.

It seems that the options are limited for doing sed operations on lines 
beyond the 4000-byte mark, so I can't say what the general solution might 
be. But at least for Libtool's purposes vis-a-vis the build in question, 
sed appears to be used consistently within that boundary.

> Now, as far as I can see, we may have conflicting requirements that
> are impossible to fulfill at the same time, on at least some Solaris
> versions.  Or is there another sed on this system that works?
> If not, then adding such a test would just break builds, which is
> quite undesirable.

Older Solaris systems don't have any fully working sed programs, but the 
XPG4 version seems to be the least broken one available. On Solaris 10, 
however, the normal sed is the one to use. (I'm afraid I don't have a 
Solaris 9 system to test...)

> Does it help, as a workaround, to add
>   save_PATH=$PATH
>   PATH=/usr/xpg4/bin:$PATH
>   export PATH
>   AC_PROG_SED
>   PATH=$save_PATH
>   export PATH
> 
> somewhere early in the configure.ac script, before any macros which
> require AC_PROG_SED (anyway before AC_PROG_LIBTOOL)?

For now, I've just added SED=/usr/xpg4/bin/sed to the build environment. It 
happens in a limited enough number of places to make this feasible.


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = address@hidden        ##  don't smell bad---    (/o|o\) /
EMAIL2 = address@hidden      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)