Hi Thomas, 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 ? In 1.5. Other quite serious bug: 3) In CVS HEAD Libtool, we use m4_ifndef([AC_PROG_SED],[ AC_DEFUN([AC_PROG_SED], [...]) ]) 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: AC_INIT AC_PROG_SED AC_OUTPUT 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. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
