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

[Ralf Wildenhues]

Hi Daniel,

thanks for the bug report.  Adding bug-autoconf to Cc:.

* Daniel Richard G. wrote on Sat, Oct 25, 2008 at 06:31:25AM CEST:
> I am migrating a build process from Libtool 1.5.x to 2.2.6a. This build
> involves programs with many dependencies, such that very long
> compiler/linker invocations are the norm.
>
> 1.5.x worked correctly for this build on both Linux and Solaris. 2.2.6a 
> works correctly on Linux, but fails on Solaris. Just prior to said failure, 
> libtool gives three "Output line too long" warnings, and a linker 
> invocation that is clearly truncated.
> 
> The problem is sed(1); more specifically, /usr/bin/sed. This is the program 
> that AC_PROG_SED finds and returns for use in the libtool script. But this 
> same program truncates its output, which makes it unsuitable for libtool.
> 
> 1.5.x, on the other hand, used /usr/xpg4/bin/sed. This one does not 
> truncate output. If I edit the 2.2.6a libtool script to use the XPG4 
> version, the build completes without further trouble.
> 
> Between 1.5.x and 2.2.x, the behavior of AC_PROG_SED changed so that now, 
> on Solaris, it chooses the broken version of sed(1).

Which Solaris version, and which Autoconf version do you use?

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.

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.


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)?

Thanks,
Ralf