building the 64bit version seems to work, building the 32bit version fails, both on amd64 emerge --info: Portage 2.2.0_alpha166-r1 (hardened/linux/amd64, gcc-4.6.3, glibc-2.16.0, 3.6.11-gentoo x86_64) ================================================================= System uname: Linux-3.6.11-gentoo-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q6600_@_2.40GHz-with-gentoo-2.2 KiB Mem: 8200180 total, 1248100 free KiB Swap: 987992 total, 895748 free Timestamp of tree: Unknown ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.6.8-r1, 2.7.3-r3 dev-util/cmake: 2.8.10.2-r1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.13.1 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.5.4, 4.6.3, 4.7.2-r1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.8 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo enlightenment sunrise multilib local Installed sets: @enlightenment, @fonts ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -ggdb" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe -ggdb" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--keep-going" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs collision-protect distlocks ebuild-locks fixlafiles force-multilib merge-sync metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms sign splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="de_DE.UTF-8" LDFLAGS="-Wl,--as-needed -Wl,--hash-style=gnu" MAKEOPTS="-j3 --load-average=8" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/enlightenment /var/lib/layman/sunrise /var/lib/layman/multilib-portage /usr/local/portage" SYNC="cvs://tommy@cvs.gentoo.org:/var/cvsroot" USE="3dnow X alsa amd64 berkdb cli cracklib crypt cups custom-cflags custom-cxxflags custom-optimization cxx dri gpm hardened java5 java6 justify mmx modules mudflap ncurses nls nptl nsplugin ogg openmp pam pax_kernel readline scanner session sse sse2 ssl tcpd unicode urandom v4l vorbis zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" MULTILIB_ABI="amd64 x86" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python2_6" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.6 2.7" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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