Created attachment 356204 [details, diff] ebuild diff gmp.h is autogenerated and needs to be wrapped which sucks but here we go with an ebuild diff. Biggest part of the diff is due to EAPI4 and removal of useless || die. FWIW: --- gmp-5.1.2-amd64/gmp.h 2013-08-16 09:03:01.407726462 -0400 +++ gmp-5.1.2-x86/gmp.h 2013-08-16 09:02:47.411626093 -0400 @@ -31,7 +31,7 @@ #if ! defined (__GMP_WITHIN_CONFIGURE) #define __GMP_HAVE_HOST_CPU_FAMILY_power 0 #define __GMP_HAVE_HOST_CPU_FAMILY_powerpc 0 -#define GMP_LIMB_BITS 64 +#define GMP_LIMB_BITS 32 #define GMP_NAIL_BITS 0 #endif #define GMP_NUMB_BITS (GMP_LIMB_BITS - GMP_NAIL_BITS) @@ -2216,7 +2216,7 @@ }; /* Define CC and CFLAGS which were used to build this version of GMP */ -#define __GMP_CC "x86_64-pc-linux-gnu-gcc -std=gnu99" +#define __GMP_CC "x86_64-pc-linux-gnu-gcc -m32 -std=gnu99" #define __GMP_CFLAGS "-march=native -mssse3 -msse4 -msse4.1 -msse4.2 -mavx -maes -O2 -pipe -ggdb3" /* Major version number is the value of __GNU_MP__ too, above and in mp.h. */
Comment on attachment 356204 [details, diff] ebuild diff OK; feel free to commit (assuming a mpfr update is coming too)
Sorry for hijacking your bug, but I think it's pretty gross that this ebuild (or at least 5.1.3 which I'm working with) applies patches to ${S} based on "use x86" -- if those patches are truly correct -- at a glance I don't see any evidence they help -- then theoretically, somehow, we are supposed to have those CFLAGS changes apply to ABI=x86 and not to ABI=amd64 :( If I drop the patch, or put it in, or whatever, I get the same results most of the time: ebuild test always succeeds unless I play with pgo. With USE=pgo, however, I get segfault test failures building x86 and a successful optimization (which I get maybe 50% of the time for both ARCH'es). I get a clean test result if I disable USE=pgo or "luck out" and optimization fails for x86. However my multi-abi gmp ebuild is quite different.... can you reproduce these results Alexis? If so, perhaps pgo should be suppressed in the per-abi compile sub-phase if [[ $ABI == x86 && $DEFAULT_ABI != x86 ]]? Anyone have a real ~x86 no-multilib lying around to try this on? I wouldn't assume, in this particular case, that results in an emulator are particularly instructive. My /proc/cpuinfo looks like: vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x600081f . . flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual my $C{,XX}FLAGS =~ -march=native and -g I'm not on a hardened profile. My toolchain is pretty standard ~amd64/gcc47 with a low "rice"-factor.
Also this should have RDEPEND="${DEPEND}" due to the EAPI bump.
except, it doesn't have either yet :) (it will, once the "abi_x86_32? ( <=app-emulation/emul-linux-baselibs-${min_emulPV} !app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)] )" is added, and the corresponding addition to the big emul-linux-x86-baselibs disjunction happens... but that's SOP and unlikely to be missed, so sorry for the noise).
(In reply to Greg Turner from comment #4) > except, it doesn't have either yet :) > > (it will, once the "abi_x86_32? ( > <=app-emulation/emul-linux-baselibs-${min_emulPV} > !app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)] )" is added, and the > corresponding addition to the big emul-linux-x86-baselibs disjunction > happens... but that's SOP and unlikely to be missed, so sorry for the noise). So sorry -- for the record (a) I'm an idiot; and (b) its not SOP, RDEPEND+=^^that^^ is wrong, and it clearly /only/ belongs in DEPEND and therefore this comment and the two before it can and should be ignored. Sorry, sometimes I should really think more and type less.
(In reply to Greg Turner from comment #2) > With USE=pgo, however, I get segfault test failures building x86 and a > successful optimization (which I get maybe 50% of the time for both > ARCH'es). I get a clean test result if I disable USE=pgo or "luck out" and > optimization fails for x86. What I did about this in my overlay can be seen here: http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob;f=dev-libs/gmp/gmp-5.1.3-r1.ebuild;h=2033d3ad398c116256e31408fb98c59f4f1ec8b0;hb=HEAD That ebuild depends on overlay-only eclasses, but one could definitely cut-paste my code from around line 120, which: o attempts to optimize three times before giving up (it seems repeated attempts to optimize -- even without recompiling anything -- may give widely varying results, and the failure rate is quite significant). o refuses to attempt pgo if: use amd64 && [[ $ABI == x86 ]], which I figured captures the criteria under which I've seen the problem fairly concisely. Of course there's a large matrix of possible unidentified causal factors -- I've done very little to dig into that, if this feature is important to anyone, they may wish to experiment with different toolchains, ABI's, crossdev, etc. to get to the bottom of this. An alternative would be to just get rid of pgo. The USE-flag basically is telling portage "hey, please make the results of emerging non-repeatable on my system" -- that's a path ebuild authors are typically encouraged not to tread. Since it's in the tree, however, I'm assuming some folks are realizing significant benefits from it, and it's worth preserving if possible.
(In reply to Greg Turner from comment #2) yes, you are completely hijacking and has nothing to do with this. please post elsewhere.
should be all set now in the tree; thanks for the report! Commit message: Add multilib support http://sources.gentoo.org/dev-libs/gmp/gmp-5.1.3-r1.ebuild?rev=1.1
