[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 18 Jan 2006 13:20:29 +0100
Thanks, several bugs for the price of one bug report.
* Thomas Porschberg wrote on Tue, Jan 17, 2006 at 08:27:45AM CET:
> I meet a problem with a configure.ac script which
> does call LT_AC_PROG_SED.
> However SED is not substituted with the sed command
> and the configure failed.
> I hardcoded SED=sed as a workaround and it worked.
1) Which package is this? LT_AC_PROG_SED is going away,
we had hoped nobody else would use it. Does the package
call it directly or does it AC_REQUIRE([LT_AC_PROG_SED])?
2) LT_AC_PROG_SED should AC_SUBST([SED]), as CVS Libtool does
in its AC_PROG_SED copy. Would that solve the issue you?
Please post the failure and some context, then try with
adding the AC_SUBST to your configure.ac and redo.
> Does the call of LT_AC_PROG_SED has any preconditions,
> what must I call before LT_AC_PROG_SED in configure.ac or
> do I need a very recent version of libtool ?
No, but it's not published interface. The next Autoconf version
has AC_PROG_SED, which should be used instead, when that is released.
> I use libtoolize (GNU libtool) 1.5.18 which comes
> with my linux distribution.
> In which version was LT_AC_PROG_SED introduced ?
Other quite serious bug:
3) In CVS HEAD Libtool, we use
This will cause aclocal (at least up to 1.7, lower than 1.9) to
always pull in this libtool.m4. Even if the user does not use
AC_PROG_LIBTOOL at all, as in:
Wouldn't it make sense to release Libtool 2.0 after Autoconf
2.60, AC_PREREQ(2.60) and drop our AC_PROG_SED? What other options
do we have? Wouldn't m4_define'ing AC_PROG_SED suffice for libtool.m4?
4) In CVS libtool, we don't provide backward compatibility for
LT_AC_PROG_SED. We probably should.
- LT_AC_PROG_SED, Thomas Porschberg, 2006/01/17
- Re: LT_AC_PROG_SED,
Ralf Wildenhues <=