Summary: | sys-libs/gdbm-1.8.3-r2 builds libgdbm_compat.so with unresolved symbols | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gergan Penkov <gpp666_999> |
Component: | New packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kanaka, XL |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 165268 | ||
Attachments: |
04_fix-gdbm-compat-linking.patch
Use libgdbm instead of -lgdbm |
Description
Gergan Penkov
2007-02-04 12:39:34 UTC
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 |