Summary: | sys-libs/db-4.6.21_p3-r1 fails with libtool-2.2.4 on g/fbsd. | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | michael <michael> |
Component: | FreeBSD | Assignee: | Gentoo/BSD Team <bsd+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | FreeBSD | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 212763 | ||
Attachments: | build_db-4.6.21_p3-r1.log |
Description
michael@smith-li.com
2008-08-17 17:12:56 UTC
Created attachment 163119 [details]
build_db-4.6.21_p3-r1.log
build log
It's a libtool-related problem, emerges fine with libtool-1.5.26, working on a fix. I don't know what are the differences between linux and freebsd, but is it possible that this problem is related to this part of the build log: /bin/bash: ./libtool: No such file or directory /bin/bash: ./libtool: No such file or directory This part comes from following configure.ac lines: if test `$LIBTOOL_PROG --config | grep build_libtool_libs | grep no` 2>/dev/null; then enable_shared="no" else enable_shared="yes" fi if test `$LIBTOOL_PROG --config | grep build_old_libs | grep no` 2>/dev/null; then enable_static="no" else enable_static="yes" fi Those checks can't be done, cause for libtool 2, libtool script is created by configure.status. But it's supposed to be possible to check for those vars (build_old_libs and build_libtool_libs) directly, even for libtool 1.5, at least if I understood certain old mail on libtool mailing list correctly (http://lists.gnu.org/archive/html/libtool/2008-04/msg00128.html). galtgendo@o2.pl: In the other versions, AC_PROG_LIBTOOL creates the libtool binary around there, but for some reason with certain versions of db, it isn't being created yet then, so $LIBTOOL_PROG is failing (actually LIBTOOL_PROG is defined as 'shell ./libtool'). Some versions of db on Linux do have the same error output, but it doesn't cause any failures (beyond the JMODSUFFIX bug in 4.2.x that I have to fix up afterwards). According to [1] the libtool script will be generated when AC_OUTPUT is called (end of configure?), feels like 'new behaviour'. Since it's used from configure, I think it be generated right after AC_PROG_LIBTOOL by calling LT_OUTPUT. Also, the "/bin/sh" might be the real cause of the problem (given that it doesn't happen on linux), being "FreeBSD sh" and not bash. [1]http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html LIBTOOL_PROG="${SHELL} ./libtool" If SHELL is defined correctly, libtool should work. Here's a really experimental patch to add LT_OUTPUT in the right places: http://rafb.net/p/lu1vDf11.html I don't know if that's actually the source of the trouble, because even with it the JMODSUFFIX in the 4.2 series still isn't defined. It seems that SHELL is defined to "/bin/bash" (I suppose "correctly"), but then libtool itself sets SHELL=${CONFIG_SHELL-/bin/sh} and then when libtool gets regenerated the function "func_append" is switched from func_append () { eval "$1=\$$1\$2" } to func_append () { eval "$1+=\$2" } Which is a bashism. I can't nail where is it doing this "wrong", but setting CONFIG_SHELL to either /bin/bash or /bin/sh on the ebuild before eautoreconf fixes the whole compilation issue (plus the added LT_OUTPUT, already had it while testing). I'm guessing some of the tools has "/bin/sh" hardcoded somewhere, still looking for it. Found it: aclocal/programs.m4:AC_PATH_TOOL(db_cv_path_sh, sh, none) aclocal/programs.m4:test "$db_cv_path_sh" = "none" && AC_MSG_ERROR([No sh utility found.]) dist # grep db_cv_path_sh Makefile.in SHELL= @db_cv_path_sh@ programs.m4 checks for "sh" then sets db_cv_path_sh to "sh" path, and Makefile sets SHELL to db_cv_path_sh, it seems this is where libtool gets confused. Actually, what I was trying to suggest, was not LT_OUTPUT, but changing those tests to simply 'test $build_libtool_libs=no', as that mail suggests that this should work even for 1.5. aclocal/programs.m4:AC_PATH_TOOL(db_cv_path_sh, sh, none) Besides Robin's patch, would it be 'wise' to replace that 'sh' with 'bash'? It sets the 'SHELL' for Makefiles only, nothing on the code/runtime. And bash is our required shell to build anyway, having the package looking for (a random)'sh' instead of bash feels wrong. Please test this patch on all of the following ebuilds: db-4.2.52_p5-r1.ebuild db-4.3.29_p1-r1.ebuild db-4.5.20_p2-r1.ebuild db-4.6.21_p3-r1.ebuild db-4.7.25_p1-r1.ebuild Index: db-4.7.25_p1-r1.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/sys-libs/db/db-4.7.25_p1-r1.ebuild,v retrieving revision 1.3 diff -p -w -b -B -u -r1.3 db-4.7.25_p1-r1.ebuild --- db-4.7.25_p1-r1.ebuild 16 Aug 2008 22:46:49 -0000 1.3 +++ db-4.7.25_p1-r1.ebuild 9 Sep 2008 00:35:17 -0000 @@ -63,6 +63,12 @@ src_unpack() { if use !bootstrap; then cd "${S}"/../dist rm -f aclocal/libtool.m4 + sed -i \ + -e '/AC_PROG_LIBTOOL$/aLT_OUTPUT' \ + configure.ac + sed -i \ + -e '/^AC_PATH_TOOL/s/ sh, none/ bash, none/' \ + aclocal/programs.m4 AT_M4DIR="aclocal aclocal_java" eautoreconf # Upstream sucks - they do autoconf and THEN replace the version variables. . ./RELEASE Works for db-4.5.20_p2-r1.ebuild, db-4.6.21_p3-r1.ebuild and db-4.7.25_p1-r1.ebuild For db-4.2.52_p5-r1.ebuild and db-4.3.29_p1-r1.ebuild the check is different: @@ -72,6 +72,12 @@ src_unpack() { # END of 4.5+earlier specific cd "${S}"/../dist rm -f aclocal/libtool.{m4,ac} aclocal.m4 + sed -i \ + -e '/AC_PROG_LIBTOOL$/aLT_OUTPUT' \ + configure.ac + sed -i \ + -e '/^AC_CHECK_TOOL/s/ sh, missing_sh/ bash, missing_sh/' \ + aclocal/programs.ac AT_M4DIR="aclocal aclocal_java" eautoreconf # Upstream sucks - they do autoconf and THEN replace the version variables. . ./RELEASE Does your modified patch let you build properly on 4.2/4.3? (In reply to comment #13) > Does your modified patch let you build properly on 4.2/4.3? > Yep, 4.2 and 4.3 build fine with it, yours is needed for 4.5+ tho. fixed in CVS |