In the configure.in for this package, the valid abilist is _incorrectly_ defined as "32 64". This _should_ be (unless I'm way off base) "amd64 x86" and any other ABIs that should be supported by this package... Reproducible: Always Steps to Reproduce: 1. emerge -v gmp on a multilib amd64 system. 2. 3. Actual Results: It fails with the following message: checking whether to enable maintainer-specific portions of Makefiles... no configure: error: ABI=amd64 is not among the following valid choices: 64 32 Expected Results: I feel that the string "32 64" is incorrect and should be corrected by the package maintainer. The only reason I need this is because I use pycrypto...heavily.
Created attachment 49628 [details] New ebuild changes ABI environment variable for this package. This ebuild fixes the issue by changing the ABI environment variable from "amd64" to "64" for building this package properly.
Created attachment 49632 [details] The one I uploaded was the old (non-functional) one for amd64. Accidentally, uploaded the original version...
Similarly, i got: checking whether make sets ${MAKE}... yes checking whether to enable maintainer-specific portions of Makefiles... no configure: error: ABI=default is not among the following valid choices: standard (dual XEON) .. worked around by adding ABI="standard" before my emerge line. Is this correct!?
Had duplicate error as comment #3 on compile 278 on a system rebuild. Added ABI="standard" to top of make.conf as stop-gap solution. Athlon 2600.
The patched ebuild, that I submitted, was amd64 specific. If you wanted it to work for any other arch., you'd have to know what ABI to specify... in the _ebuild_, not in your environment. Look at the second attachment, above, to see what I mean. Specifically, in the src_compile() section add the following based upon what arch. and what ABI you're compiling for... NOTE: There are only two ABIs that gmp supports: 32 or 64. use <arch> && export ABI="[32|64]"; For x86 arch., this would look like: use x86 && export ABI="32" For amd64 arch.: use amd64 && export ABI="32" However...in looking at the latest ebuild, all of this ABI stuff should be fixed. If it isn't, I'd recommend filing a new bug. Cheers, - Brendan
on another note don't put "ABI="standard" in the top of make.conf" it WILL cause your next ncurses emerge to fail
*** Bug 81913 has been marked as a duplicate of this bug. ***
eradicator - this seems to be related to the patch you added gmp-4.1.4-multilib.patch. As a stop gap I've added. if use amd64 export ABI=64 else export ABI=standard fi Not sure what should be done for ppc64 Also of note NONE of the patches have been submitted upstream that I know of. gmp-bugs@swox.com
If you set ABI to standard or 64, a TON of stuff will break (including $(get_lindir), so you'll have libs in /usr). Don't set it unless you know what you're doing. multilib.eclass sets it to 'deffault' if it's not set. This bug was fixed with the gmp-4.1.4-multilib.patch to not have the gmp build system use the ABI environment variable... the problem was that it was conditionally applied at a time when ABI was only set in multilib profiles. The real fix is to unconditionally apply that patch. Fixed in cvs.
Oh and regarding sending the patch upstream... I don't really think that's neccesary as it's really a gentoo-specific problem that we use ${ABI} for our toolchain, and they've decided to use ${ABI} for something else. Thanks for catching this, btw.
Hi. >>Fixed in cvs. Yes but when does that affect me? I need the package but I can
Hi. >>Fixed in cvs. Yes but when does that affect me? I need the package but I cant install it! What should I do?
chillout - wait a bit. emerge sync and try again.
stable on ppc64
*** Bug 82092 has been marked as a duplicate of this bug. ***
The Changelog has changed, saying this bug is corrected, but i still get the error.
Needs to be reopened. The files/gmp-4.1.4-multilib.patch is indeed applied, but gmp still fails to build. I had to do ABI=standard emerge gmp To get it to go. I'm on a bog standard x86 machine (ok, it's SMP, but whatever) so perhaps that case is now being missed out.
ah yep, it was only running autoreconf on some archs... resync and it should be fixed soon.
*** Bug 82136 has been marked as a duplicate of this bug. ***
*** Bug 82188 has been marked as a duplicate of this bug. ***
