| Summary: | >=dev-libs/libffi-3.0.12 breaks dev-libs/glib compilation on multilib-portage/cross-compile | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Thomas Sachau <tommy> |
| Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ssuominen, toolchain |
| Priority: | Normal | ||
| Version: | autobuilds | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
build.log for target ABI=amd64 build.log for target ABI=x86 |
||
|
Description
Thomas Sachau
2013-03-23 16:01:57 UTC
Created attachment 342994 [details]
build.log
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libffi.so when searching for -lffi not to ask the obvious, but is /usr/lib/libffi.so 32bit ? file /usr/lib/libffi.so /usr/lib/libffi.so: symbolic link to `libffi.so.6.0.0' file /usr/lib/libffi.so.6.0.0 /usr/lib/libffi.so.6.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped Since the target is x86/32bit on amd64, it should use /usr/lib32/libffi.so instead. (In reply to comment #3) and same with 3.0.13? (In reply to comment #3) use the -L option to file. it is your friend. i think you mean that "because you have the crap multilib symlink enabled, 32bit should be searching /usr/lib32/ instead of /usr/lib/". so show the `file` output of the /usr/lib32/ paths. the link line isn't specifying -L or -rpath itself to any system paths. that means the compiler itself (via -m32) should be looking at ../lib32 for os paths. or one of the libs you're linking in has bad RPATH entries to /usr/lib. run `gcc -print-multi-os-directory -m32` to make sure it's set correctly. the other -l flags used are glibc so the rpath angle shouldn't be a problem. (In reply to comment #4) > (In reply to comment #3) > > and same with 3.0.13? yes (In reply to comment #5) > (In reply to comment #3) > > use the -L option to file. it is your friend. > > i think you mean that "because you have the crap multilib symlink enabled, > 32bit should be searching /usr/lib32/ instead of /usr/lib/". so show the > `file` output of the /usr/lib32/ paths. > > the link line isn't specifying -L or -rpath itself to any system paths. > that means the compiler itself (via -m32) should be looking at ../lib32 for > os paths. or one of the libs you're linking in has bad RPATH entries to > /usr/lib. > > run `gcc -print-multi-os-directory -m32` to make sure it's set correctly. > the other -l flags used are glibc so the rpath angle shouldn't be a problem. $ gcc -print-multi-os-directory -m32 ../lib32 If there would be general issues with my setup, then it is very unlikely that everything else works and even libffi up to 3.0.11 is fine and only libffi version 3.0.12 or higher show issues. (In reply to comment #6) `emerge libffi` only installs a 64bit version. i don't run the multilib code you're running, so it isn't an issue for everyone. just to clarify: i only see this issue, when compiling for x86 on amd64, just compiling the usual 64bit parts on amd64 does not show this issue. Bug 452758 might be related, also an issue with >=libffi-3.0.12 and also only occurs, when compiling 32bit versions on amd64. (In reply to comment #8) you really need to post the `file` output asked for. full build log for *libffi* itself would also be useful. (In reply to comment #9) > (In reply to comment #8) > > you really need to post the `file` output asked for. full build log for > *libffi* itself would also be useful. $ file -L /usr/lib32/libffi.so /usr/lib32/libffi.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped Created attachment 343409 [details]
build.log for target ABI=amd64
Created attachment 343411 [details]
build.log for target ABI=x86
(In reply to comment #10) and what is providing that exactly ? according to your build logs, libffi isn't installing that. the ABI=amd64 log shows: libtool: install: /usr/bin/install -c .libs/libffi.so.6.0.1 /mnt/portage/tmp/portage/dev-libs/libffi-3.0.13/image//usr/lib64/../lib64/libffi.so.6.0.1 while the ABI=x86 log shows: libtool: install: /usr/bin/install -c .libs/libffi.so.6.0.1 /mnt/portage/tmp/portage/dev-libs/libffi-3.0.13/image//usr/lib32/../lib64/libffi.so.6.0.1 seems like FEATURES=multilib-strict should be catching that error reading the libffi configure.ac, it looks like warts from the gcc build system. it's trying to be clever and discover toolexeclibdir. it's probably this snippet that ends up screwing you: multi_os_directory=`$CC -print-multi-os-directory` case $multi_os_directory in .) ;; # Avoid trailing /. ../*) toolexeclibdir=$toolexeclibdir/$multi_os_directory ;; there doesn't seem to be a configure flag that'd force sanity here for us. maybe the simplest thing is to do in src_prepare: sed -i 's:@toolexeclibdir@:$(libdir):g' Makefile.in Seems like i mixed 2 mistakes: 1. Since >=libffi-3.0.12 cause failures for depending packages, i reverted back to libffi-3.0.11, so the file commands have been with libffi-3.0.11 2. Since @preserved-rebuild feature of portage preserves the 32bit libs of libffi-3.0.11 and marks them as being part of libffi-3.0.13, it looks at first glance, as if libffi-3.0.13 has 32bit libs installed. So you are right: >=libffi-3.0.12 dont install 32bit libs in /usr/lib32 so 32bit libs get lost and the existing 32bit parts (/usr/lib32/libffi.so.6 -> libffi.so.6.0.0) are preserved by portage from the previous working version. (In reply to comment #14) can you try the one line fix i suggested ? sed -i 's:@toolexeclibdir@:$(libdir):g' Makefile.in in src_prepare allows to build both glib and python again, so fixes this bug and bug 452758 (In reply to comment #16) i've made that change then to .11, .12, and .13. the code looks largely unchanged between them, so i don't really know why you say .11 works but .12+ fail. not really worth investigating. should be all set now in the tree; thanks for the report! Commit message: Disable tooldir related hack that breaks --libdir usage http://sources.gentoo.org/dev-libs/libffi/libffi-3.0.11.ebuild?r1=1.19&r2=1.20 http://sources.gentoo.org/dev-libs/libffi/libffi-3.0.12.ebuild?r1=1.2&r2=1.3 http://sources.gentoo.org/dev-libs/libffi/libffi-3.0.13.ebuild?r1=1.1&r2=1.2 |