GMP 4.2 make check failures
Samuelson, Gary M
gary.samuelson at verizon.com
Fri Feb 6 17:40:42 CET 2009
Thanks for the assistance. Using ABI=32 resulted in all the 'make check' tests passing.
Of course, I intended to download the latest release.
I have no explanation for getting 4.2, rather than 4.2.4.
I'm not even sure which site it came from.
I checked, as advised in the online manual, Known Build Problems and Notes for Particular Systems, and did not find any reference to the ELF error.
As for searching the mailing lists, I don't see a search tool.
The output from 'make check' invited me to send a report, so I did.
Again thanks for the help.
From: Marc Glisse [mailto:marc.glisse at normalesup.org]
Sent: Friday, February 06, 2009 2:17 AM
To: Samuelson, Gary M
Cc: gmp-bugs at swox.com
Subject: Re: GMP 4.2 make check failures
On Thu, 5 Feb 2009, Samuelson, Gary M wrote:
> GMP version 4.2
Is this 4.2 As in 4.2.0? This is a really old version, you should get 4.2.4, assuming that 4.3.0 is not out yet.
> ld.so.1: t-bswap: fatal: /usr/local/lib/libgcc_s.so.1: wrong ELF class:
You should really check the archives of the mailing list. gcc comes with broken specs by default. Ways to work around it include modifying these specs, adding -R/usr/local/lib/sparcv9 to LDFLAGS, defining LD_LIBRARY_PATH_64, using crle, etc. But my guess is that you are actually more interested in the 32 bit version of gmp, so you could try:
Note that the 64 bit version is currently faster if you want to use gmp for intensive computation.
(I am a bit surprised that the 32 bit version can't be made almost as fast, since from what I understand both have access to the same instructions, as I was reminded reading:
but I know the people who wrote the gmp code know much more than I do about this, and the 32 bit code already uses 64 bit instructions in some
> SPROcc Sun Studio 11 C Compiler
> (sparc) 11.0,REV=2005.10.13
Does it have the latest patches?
> mpn_get_d wrong on random data
> sign 0
> n =0x1FF800FE007FC0
> nsize 1
> exp -37
> want =[43 3F F8 00 FE 00 7F C0] 8998407423164352
> got =[40 EF F8 00 FE 00 7F C0] 65472.031006097327918
> FAIL: t-get_d
There, the archives of the mailing list suggest this is caused by an unsafe optimization triggered by the -fast flag in Sun Studio. I believe replacing -fsimple=1 with -fsimple=0 is enough to work around it, but it may be easier to just specify your own CFLAGS that don't include -fast.
More information about the gmp-bugs