sys-libs/gbdm-1.8.3-r04.1 failed to build with the following error /Users/naota/Gentoo/bin/bash ./libtool /Users/naota/Gentoo/usr/bin/install -c -c libgdbm_compat.la \ /Users/naota/Gentoo/var/tmp/portage/sys-libs/gdbm-1.8.3-r04.1/image//Users/naota/Gentoo/usr/lib/libgdbm_compat.la libtool: install: warning: relinking `libgdbm_compat.la' cd /Users/naota/Gentoo/var/tmp/portage/sys-libs/gdbm-1.8.3-r04.1/work/gdbm-1.8.3; /bin/sh ./libtool --mode=relink i686-apple-darwin10-gcc -Wl,-dead_strip_dylibs -o libgdbm_compat.la -rpath /Users/naota/ 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 lib gdbm.la -inst-prefix-dir /Users/naota/Gentoo/var/tmp/portage/sys-libs/gdbm-1.8.3-r04.1/image/ i686-apple-darwin10-gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libgdbm_compat.3.0.0.dylib dbminit.lo delete.lo fetch.lo store.lo seq.lo close.lo dbmopen.lo dbmdelete.lo dbmfetch.lo db mstore.lo dbmseq.lo dbmclose.lo dbmdirfno.lo dbmpagfno.lo dbmrdonly.lo /Users/naota/Gentoo/usr/lib/libgdbm.dylib -lc -dead_strip_dylibs -install_name /Users/naota/Gentoo/usr/lib/libgdbm_compat.3.dylib -compatibility_version 4 -current_version 4.0 i686-apple-darwin10-gcc: /Users/naota/Gentoo/usr/lib/libgdbm.dylib: No such file or directory libtool: install: error: relink `libgdbm_compat.la' with the above command before installing it make: *** [install-compat] エラー 1 emake failed seems bug #223865 problem again? Reproducible: Always
Looks like it builds OK (on Darwin) if you comment out the two following lines: #epatch "${FILESDIR}"/${P}-compat-linking.patch #165263, #223865 #epatch "${FILESDIR}"/${P}-build.patch #209730
I can confirm this for a crossdev setup with armv7a-hardfloat-linux-gnueabi. Will provide logs if needed, but it's the same error messages, except .so instead of .dynlib of course. Mikes workaround also fixes it for me.
(In reply to comment #2) > I can confirm this for a crossdev setup with armv7a-hardfloat-linux-gnueabi. > Will provide logs if needed, but it's the same error messages, except .so > instead of .dynlib of course. > > Mikes workaround also fixes it for me. Same exact issue for me on Mac OSX 10.5. I can confirm that Mike's workaround also fixes the build for me... ~jtriley
Any progress on that? Had to fix this on a new installed prefix system. Not so impressive
sorry, haven't had the time to reproduce this yet
reproduced on Lion, not yet clear to me what's going on, though
Same issue on Lion, Mike's workaround works here.
(In reply to comment #1) > Looks like it builds OK (on Darwin) if you comment out the two following lines: > > > #epatch "${FILESDIR}"/${P}-compat-linking.patch #165263, #223865 > #epatch "${FILESDIR}"/${P}-build.patch #209730 Probably bit offtopic, but can somebody explain me why leaving the second epatch uncommented halts the unpack process? It seems to me that the first epatch does not affect those Makefile.in rows patched by the second epatch.
Ok, I think I squashed this thing, finally. Sorry for the long waits. It seemed libtool wasn't really doing what it should. I just inserted an eautoreconf to get a new(er) libtool in (from the prefix), and that made things just work correctly. (In reply to comment #2) > I can confirm this for a crossdev setup with armv7a-hardfloat-linux-gnueabi. > Will provide logs if needed, but it's the same error messages, except .so > instead of .dynlib of course. > > Mikes workaround also fixes it for me. Please file a bug against base-system for this. Perhaps the same fix works for you, but I've only added the fix to the prefix tree. This includes the patch I needed to get the makefile working with newer libtool.
