Created attachment 378980 [details] Build log for dev-libs_libffi-3.1-r3 The interactive mode of bootstrap-prefix.sh trundled along to the penultimate step: the emerge -e system to rebuild the @system set using the full Gentoo toolchain. Things seem to fly along well enough with ACCEPT_KEYWORDS="~x86-macos"--until they went off the rails. First off, I found that when the interactive script halted I was left alone in the woods. <quote>Oh yeah, I thought I was almost there, and then this! I did emerge -e system and it failed at some point :( Details might be found in the build log: /Users/mike/gentoo/var/tmp/portage/dev-libs/libffi-3.1-r3/temp/build.log I have no clue, really. Please find friendly folks in #gentoo-prefix on irc.gentoo.org, gentoo-alt@lists.gentoo.org mailing list, or file a bug at bugs.gentoo.org under Gentoo/Alt, Prefix Support. You know, I got the feeling you just started to like me, but I guess that's all gone now. I'll bother you no longer.</quote> A look through bootstrap-prefix.sh showed that I was near the end of the process--so close to home. These lines stood out for me in the emerge output: /Users/mike/gentoo/var/tmp/portage/dev-libs/libffi-3.1-r3/work/libffi-3.1/src/x86/win32.S:unknown:missing indirect symbols for section (__IMPORT,__jump_table) Makefile:1322: recipe for target 'src/x86/win32.lo' failed make[2]: *** [src/x86/win32.lo] Error 1 This made me curious about recent versions of libffi. The changelog for libffi v3.1 (https://github.com/atgreen/libffi/blob/master/ChangeLog.libffi-3.1) has these telling lines: <quote>This introduces FFI_STDCALL, FFI_THISCALL, and FFI_FASTCALL on non-Windows x86-32 platforms, as non-default calling conventions.</quote> I don't know if this was the actual problem, but I see there were several other changes related to non-Windows x86 in libffi 3.1. This gave me the idea for the workaround: try staying with the non-keyworded libffi. Now I had another problem: I could not enable the Prefix. I had never used Gentoo Prefix before, so I wasn't sure how. The bootstrap-prefix.sh script is supposed to set up a {$PREFIX}/startprefix script, but it had not yet done so by the point of the failure. First I tried the solution the bootstrap-prefix.sh script itself uses: bootstrap-prefix.sh /Users/mike/gentoo startscript but bootstrap-prefix.sh evidently requires some set of environment variables to be set up already: * Bootstrapping Gentoo prefixed portage installation using * host: i386-apple-darwin10 * prefix: /Users/mike/gentoo/ * ready to bootstrap startscript * Trying to emerge the shell you use, if necessary by running: * emerge -u bash ../bootstrap-prefix.sh: line 451: emerge: command not found !!! Your shell is not available in portage, hence we cannot !!! automate starting your prefix, set SHELL and rerun this script So now the manual method: copy the $PREFIX/usr/portage/scripts/startprefix.in script to $PREFIX/startprefix, substitute the value of $PREFIX for instances of @GENTOO_PORTAGE_EPREFIX@ (Mac OS includes vim!), make the file executable, and then run it to enter the prefix. Now that I was finally in Gentoo userland, I ran emerge -vp libffi and found that version 3.0.13-r1 was installed and that now emerge wanted to update it to 3.1-r3, the most recent keyworded version. Now the workaround theory (and the reason to post this bug): try emerging the stable version instead. emerge -v1 =dev-libs/libffi-3.0.13-r1 Now, following this with an emerge -v --resume --skip-first gave me a usable Gentoo Prefix. (I did see that emerge stop because of a bus error. A bus error! The drive went unaccessible. I thought Macs were supposed to have such a high build quality and all. A reboot--snicker, snicker--fixed it. I ssh'ed back in and resumed the emerge.) Of note--and maybe I was being too hard on the Macintosh--I was doing this on an old MacBook that has a Core Duo (not Core 2 Duo) processor. The bug may not show up in the 64-bit version. As one more confirmation, I tried emerging v3.1-r3 once more time after everything else in @system was nice and compiled for Gentoo. Still failed. Maybe the best fix for now for this bug would be to change the gentoo_prefix:prefix/darwin/macos/*/x86 profiles to make ACCEPT_KEYWORDS="x86-macos" for dev-libs/libffi to avoid v3.1 of libffi. There have been bugs filed for libffi-3.1 with the upstream, including from our own Samuli Suominen. So for the near term, it sure would be kind to Gentoo Prefix users to not expose them to libffi-3.1 until it gets fixed. This is the output of emerge --info Portage HEAD (prefix/darwin/macos/10.6/x86, gcc-4.2.1, unavailable, 10.0.0 i386) ================================================================= System uname: Darwin-10.0.0-i386-32bit Timestamp of tree: Sat, 14 Jun 2014 05:06:46 +0000 distcc 2.18.5-Apple.1 i386-apple-darwin10.0 (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 4.2_p45-r1 dev-lang/python: 2.7.6-r1, 3.3.3 dev-util/pkgconfig: 0.28-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.14 sys-devel/gcc-config: 1.8-r00.1 sys-devel/libtool: 2.4.2 sys-devel/make: 4.0-r1 Repositories: gentoo_prefix ACCEPT_KEYWORDS="~x86-macos" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-apple-darwin10" CFLAGS="-march=prescott -O2 -pipe" CHOST="i686-apple-darwin10" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/terminfo" CXXFLAGS="-march=prescott -O2 -pipe" DISTDIR="/Users/mike/gentoo/usr/portage/distfiles" FCFLAGS="" FEATURES="assume-digests binpkg-logs collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles force-prefix merge-sync news nostrip parallel-fetch preserve-libs protect-owned sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-dead_strip_dylibs" MAKEOPTS="-j2" PKGDIR="/Users/mike/gentoo/usr/portage/packages" PORTAGE_CONFIGROOT="/Users/mike/gentoo/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/Users/mike/gentoo/var/tmp" PORTDIR="/Users/mike/gentoo/usr/portage" PORTDIR_OVERLAY="" USE="aqua coreaudio cracklib cxx ipv6 mmx mmxext modules ncurses nls objc objc++ prefix readline sse sse2 ssl unicode x86-macos zlib" 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 author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="Darwin" 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 ublox ubx" INPUT_DEVICES="keyboard mouse" KERNEL="Darwin" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" 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" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
Got the same error when updating.
I've looked into this issue, changed the asm stuff somewhat, but there's something that bugs the (outdated) gcc compiler. I fear our only option is to mask this package on x86, as removing win32.S from targets has an effect on the rest of the process.
Created attachment 380578 [details, diff] remove win32 calls This patch brings back a couple of defines from libffi-3.0.
LGTM cannot test right now
I'm wondering whether this patch will break x86, x86-freebsd, x86-solaris, etc. All x86 targets get this win32 thing by default now, isn't it?
I'm on 10.7.5 (Lion) in a 32-bits Prefix having the same problem.
(In reply to Fabian Groffen from comment #5) > I'm wondering whether this patch will break x86, x86-freebsd, x86-solaris, > etc. All x86 targets get this win32 thing by default now, isn't it? Yeah, it needs some more ifdef's around.
Masked for the time being
*** This bug has been marked as a duplicate of bug 536764 ***
