I have found this as a side effect to a python problem, in which the dbm module fails to build. The problem is: ldd -r /usr/lib/libgdbm_compat.so.3.0.0 undefined symbol: _gdbm_memory (./libgdbm_compat.so.3.0.0) undefined symbol: _gdbm_fetch_val (./libgdbm_compat.so.3.0.0) undefined symbol: gdbm_errno (./libgdbm_compat.so.3.0.0) undefined symbol: _gdbm_file (./libgdbm_compat.so.3.0.0) undefined symbol: gdbm_nextkey (./libgdbm_compat.so.3.0.0) undefined symbol: gdbm_delete (./libgdbm_compat.so.3.0.0) undefined symbol: gdbm_firstkey (./libgdbm_compat.so.3.0.0) undefined symbol: gdbm_fetch (./libgdbm_compat.so.3.0.0) undefined symbol: gdbm_store (./libgdbm_compat.so.3.0.0) undefined symbol: gdbm_close (./libgdbm_compat.so.3.0.0) undefined symbol: gdbm_open (./libgdbm_compat.so.3.0.0) linux-gate.so.1 => (0xb7f6c000) libc.so.6 => /lib/libc.so.6 (0xb7df9000) /lib/ld-linux.so.2 (0x80000000) I will attach a patch from debian, which resolves the problem, making libgdbm_compat link to libgdbm
Created attachment 109108 [details, diff] 04_fix-gdbm-compat-linking.patch patch from debian, which resolves the problem
added to 1.8.3-r3, cheers
... and "-r3" fails on systems having MAKEOPTS="-jN" with N >= 2, because of substituting "make" by "emake": ------------------------------------------------------------------------- src_install() { - make INSTALL_ROOT="${D}" install install-compat || die + emake INSTALL_ROOT="${D}" install install-compat || die mv "${D}"/usr/include/gdbm/gdbm.h "${D}"/usr/include/ || die dodoc ChangeLog NEWS README } ------------------------------------------------------------------------- Here are the "-r3" ebuild's famous last words: ------------------------------------------------------------------------- >>> Install gdbm-1.8.3-r3 into /var/tmp/portage/gdbm-1.8.3-r3/image/ category sys-libs ./mkinstalldirs /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib \ /var/tmp/portage/gdbm-1.8.3-r3/image//usr/include/gdbm /var/tmp/portage/gdbm-1.8.3-r3/image//usr/share/man/man3 \ /var/tmp/portage/gdbm-1.8.3-r3/image//usr/share/info ./mkinstalldirs /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib \ /var/tmp/portage/gdbm-1.8.3-r3/image//usr/include/gdbm mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr mkdir: cannot create directory `/var/tmp/portage/gdbm-1.8.3-r3/image//usr': File exists mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib mkdir: cannot create directory `/var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib': File exists mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/include mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/include mkdir: cannot create directory `/var/tmp/portage/gdbm-1.8.3-r3/image//usr/include': File exists mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/include/gdbm mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/include/gdbm mkdir: cannot create directory `/var/tmp/portage/gdbm-1.8.3-r3/image//usr/include/gdbm': File exists /bin/sh ./libtool /bin/install -c -c libgdbm_compat.la \ /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib/libgdbm_compat.la mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/share mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/share/man mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/share/man/man3 mkdir /var/tmp/portage/gdbm-1.8.3-r3/image//usr/share/info make: *** [install] Error 1 make: *** Waiting for unfinished jobs.... /bin/install -c -c .libs/libgdbm_compat.so.3.0.0 /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib/libgdbm_compat.so.3.0.0 (cd /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib && rm -f libgdbm_compat.so.3 && ln -s libgdbm_compat.so.3.0.0 libgdbm_compat.so.3) (cd /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib && rm -f libgdbm_compat.so && ln -s libgdbm_compat.so.3.0.0 libgdbm_compat.so) /bin/install -c -c .libs/libgdbm_compat.lai /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib/libgdbm_compat.la /bin/install -c -c .libs/libgdbm_compat.a /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib/libgdbm_compat.a i686-pc-linux-gnu-ranlib /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib/libgdbm_compat.a chmod 644 /var/tmp/portage/gdbm-1.8.3-r3/image//usr/lib/libgdbm_compat.a libtool: install: warning: remember to run `libtool --finish /usr/lib' /bin/install -c -m 644 ./dbm.h /var/tmp/portage/gdbm-1.8.3-r3/image//usr/include/gdbm/dbm.h /bin/install -c -m 644 ./ndbm.h /var/tmp/portage/gdbm-1.8.3-r3/image//usr/include/gdbm/ndbm.h !!! ERROR: sys-libs/gdbm-1.8.3-r3 failed. Call stack: ebuild.sh, line 1546: Called dyn_install ebuild.sh, line 1020: Called src_install gdbm-1.8.3-r3.ebuild, line 33: Called die !!! (no error message) !!! If you need support, post the topmost build error, and the call stack if relevant. ------------------------------------------------------------------------- Cheers, Axel
This "fix" breaks cross-compile (because it tries to link with the build system's installed gdbm). For native compile, if gdbm is not already installed you get a big libtool warning during compile. I think the right patch is something more like this. I'll attach what I think is a more appropriate patch.
Created attachment 109365 [details, diff] Use libgdbm instead of -lgdbm
well that's also wrong :P fixed in cvs by giving libtool the gdbm linker script
The current patch in CVS makes the compilation dependent on an installed gdbm, as it links against an existing gdbm library. If it isn't installed yet, compilation fails. Second issue is that because of the dependency on itself, some linkers get into an endless loop when loading symbols, because of the circular dependency introduced.
define 'current patch' the version in cvs right now builds fine for me without gdbm installed
Excuse all the c&p's for file contents, I'm in the middle of emerge'ng a system (and they're more informational that needed-files anyways). I don't yet understand the relationship between prefix-portage, being "experimental" and all, and portage, but if appropriate, someone else in-the-know should probably reopen this bug. So, this patch: <snip from="gdbm-1.8.3-r3.ebuild"> epatch "${FILESDIR}"/${P}-compat-linking.patch #165263 </snip> ... seems the same between portage proper and prefix-portage (as well as the ebuild, minus the EAPI changes and such). <patch name="gdbm-1.8.3-compat-linking.patch"> Since libgdbm_compat uses libgdbm, make sure we link it in. http://bugs.gentoo.org/165263 --- gdbm-1.8.3/Makefile.in +++ gdbm-1.8.3/Makefile.in @@ -161,10 +161,10 @@ $(LIBTOOL) --mode=link $(CC) -o libgdbm.la -rpath $(libdir) \ -version-info $(SHLIB_VER) $(LOBJS) -libgdbm_compat.la: $(C_LOBJS) gdbm.h +libgdbm_compat.la: $(C_LOBJS) gdbm.h libgdbm.la rm -f libgdbm_compat.la $(LIBTOOL) --mode=link $(CC) -o libgdbm_compat.la -rpath $(libdir) \ - -version-info $(SHLIB_VER) $(C_LOBJS) + -version-info $(SHLIB_VER) $(C_LOBJS) libgdbm.la gdbm.h: gdbm.proto gdbmerrno.h gdbm.proto2 rm -f gdbm.h </patch> In prefix-portage, on x86-macos, the generated libgdbm.la file (still in the WORKDIR) is: <file name="libgdbm.la"> # libgdbm.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.4.2 (1.922.2.53 2001/09/11 03:18:52) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libgdbm.3.dylib' # Names of this library. library_names='libgdbm.3.0.0.dylib libgdbm.3.dylib libgdbm.dylib' # The name of the static archive. old_library='libgdbm.a' # Libraries that this one depends upon. dependency_libs='' # Version information for libgdbm. current=3 age=0 revision=0 # Is this an already installed library? installed=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/Users/fafhrd/Library/Gentoo/usr/lib' </file> ... and for good measure, here's the libgdbm_compat.la". Note the -rpath in there. Does that work on *-macos? Or does libtool know what to do per-platform when it gets an -rpath option? <file name="libgdbm_compat.la"> # libgdbm_compat.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.4.2 (1.922.2.53 2001/09/11 03:18:52) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libgdbm_compat.3.dylib' # Names of this library. library_names='libgdbm_compat.3.0.0.dylib libgdbm_compat.3.dylib libgdbm_compat.dylib' # The name of the static archive. old_library='libgdbm_compat.a' # Libraries that this one depends upon. dependency_libs=' /Users/fafhrd/Library/Gentoo/var/tmp/portage/sys-libs/gdbm-1.8.3-r3/work/gdbm-1.8.3/libgdbm.la ' # Version information for libgdbm_compat. current=3 age=0 revision=0 # Is this an already installed library? installed=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/Users/fafhrd/Library/Gentoo/usr/lib' relink_command="cd /Users/fafhrd/Library/Gentoo/var/tmp/portage/sys-libs/gdbm-1.8.3-r3/work/gdbm-1.8.3; /bin/sh ./libtool --mode=relink i686-apple-darwin8-gcc -o libgdbm_compat.la -rpath /Users/fafhrd/Library/Gentoo/usr/lib -version-info 3 0 0 dbminit.lo delete.lo fetch.lo store.lo seq.lo close.lo dbmopen.lo dbmdelete.lo dbmfetch.lo dbmstore.lo dbmseq.lo dbmclose.lo dbmdirfno.lo dbmpagfno.lo dbmrdonly.lo libgdbm.la @inst_prefix_dir@" </file>
... additionally, and probably specifically for *-macos on prefix-portage, commenting out the epatch line entirely, and re-digesting, allows gdbm to build on a fresh prefix-portage install.
i'm pretty sure you're dealing with an entirely different issue ... libtool may not be doing the "right thing" i doubt telling libtool to include libgdbm via the linker script is incorrect if you want to track the issue, please file a new bug and let the prefix guys look into it
