Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 235025

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: FreeBSDAssignee: Gentoo/BSD Team <bsd+disabled>
Severity: normal CC: base-system
Priority: High    
Version: unspecified   
Hardware: All   
OS: FreeBSD   
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 212763    
Attachments: build_db-4.6.21_p3-r1.log

Description 2008-08-17 17:12:56 UTC
During emerge -e system of a new gfbsd install, db fails.

libtool: link: i686-gentoo-freebsd6.2-gcc  ./.libs/ -pthread
/usr/lib/gcc/i686-gentoo-freebsd6.2/4.1.2/../../../crt1.o: In function `_start':
crt1.c:(.text+0x77): undefined reference to `main'
collect2: ld returned 1 exit status
gmake: *** [berkeley_db_svc] Error 1

Reproducible: Always

Steps to Reproduce:

Portage 2.2_rc8 (default-bsd/fbsd/6.2/x86, gcc-4.1.2, freebsd-lib-6.2-r4, 6.2-RELEASE i386)
System uname: FreeBSD-6.2-RELEASE-i386-32bit
Timestamp of tree: Sun, 17 Aug 2008 07:00:01 +0000
app-shells/bash:     3.2_p39
dev-lang/python:     2.4.4-r6
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 2.0.0
sys-apps/openrc:     0.2.5
sys-devel/autoconf:  2.62-r1
sys-devel/automake:  1.10.1-r1
sys-devel/binutils:  2.17-r2
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   2.2.4
virtual/os-headers:  6.2-r4
ACCEPT_KEYWORDS="x86-fbsd ~x86-fbsd"
CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer"
FEATURES="collision-protect distlocks parallel-fetch preserve-libs sfperms strict unmerge-orphans userfetch"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="berkdb cli cracklib crypt cups dri gdbm iconv java5 midi ncurses nls oss pam pcre perl postgres ppds python readline reflection session spl ssl tcpd unicode x86-fbsd zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="FreeBSD" INPUT_DEVICES="keyboard mouse" KERNEL="FreeBSD" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="BSD" VIDEO_CARDS="apm ark chips cirrus cyrix dummy i128 i810 mach64 mga 	neomagic nv r128 radeon rendition s3 s3virge savage siliconmotion sis 	sisusb tga trident tseng vga via vmware"
Comment 1 2008-08-17 17:13:51 UTC
Created attachment 163119 [details]

build log
Comment 2 Javier Villavicencio (RETIRED) gentoo-dev 2008-08-17 21:52:16 UTC
It's a libtool-related problem, emerges fine with libtool-1.5.26, working on a fix.
Comment 3 Rafał Mużyło 2008-08-17 22:55:40 UTC
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 lines:
if test `$LIBTOOL_PROG --config |
    grep build_libtool_libs | grep no` 2>/dev/null; then
if test `$LIBTOOL_PROG --config |
    grep build_old_libs | grep no` 2>/dev/null; then

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 (
Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-08-17 23:03:56 UTC
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).
Comment 5 Javier Villavicencio (RETIRED) gentoo-dev 2008-08-17 23:42:05 UTC
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.

Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-08-18 00:13:18 UTC
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:

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.
Comment 7 Javier Villavicencio (RETIRED) gentoo-dev 2008-08-18 00:29:38 UTC
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"


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.
Comment 8 Javier Villavicencio (RETIRED) gentoo-dev 2008-08-18 00:34:02 UTC
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
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.
Comment 9 Rafał Mużyło 2008-08-18 09:08:36 UTC
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.
Comment 10 Javier Villavicencio (RETIRED) gentoo-dev 2008-09-03 10:36:01 UTC
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.
Comment 11 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-09-09 00:36:29 UTC
Please test this patch on all of the following ebuilds:

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 \
+		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
Comment 12 Javier Villavicencio (RETIRED) gentoo-dev 2008-09-09 03:30:44 UTC
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' \
+               sed -i \
+                       -e '/^AC_CHECK_TOOL/s/ sh, missing_sh/ bash, missing_sh/' \
+                       aclocal/
                AT_M4DIR="aclocal aclocal_java" eautoreconf
                # Upstream sucks - they do autoconf and THEN replace the version variables.
                . ./RELEASE
Comment 13 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-09-09 03:40:01 UTC
Does your modified patch let you build properly on 4.2/4.3?
Comment 14 Javier Villavicencio (RETIRED) gentoo-dev 2008-09-09 05:03:15 UTC
(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.
Comment 15 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-09-09 05:38:11 UTC
fixed in CVS