Bugzilla Bug 165263

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 an attachment (id=109108) [details]
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 an attachment (id=109365) [details]
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