[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'make check' on Win 2k
Re: 'make check' on Win 2k
Mon, 05 Jan 2004 22:15:25 +1100
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313
Kevin Ryde wrote:
Sisyphus <address@hidden> writes:
/bin/sh: ./t-bswap.exe: No such file or directory
Hmm. Automake and libtool are fighting. I wonder why nobody reported
this before. Maybe nobody with mingw ever did a make check! :-)
(I've done a make check, but only in wine.)
The problem is that libtool makes a t-bswap shell script, which runs
.libs/t-bswap.exe. But automake rewrites the check_PROGRAMS list to
say t-bswap.exe and tries to run that instead of of plain t-bswap.
I see - wrong diagnosis on my part - since the files are being built
exactly where they oughtta be. An alternative workaround for me would be
to rename 't-bswap' to 't-bswap.exe', etc. and not have to copy any files.
proceeds to build the 5 mpn test executables, again in the wrong
Re-building of the .exe's is a known problem (Windows DLL test
programs). Annoying, but not harmful in itself.
Ooops ... poor choice on my part to use "again". There's no re-building
going on at all.
All I meant was that the 5 "tests" executables get built in the wrong
place, then after I've fixed that up the 5 "tests/mpn" executables get
built in the wrong place, then after I've fixed that up the 52
"tests/mpz" executables get built in the wrong place. (Except now I know
that they're not being built in the "wrong place" at all :-)
I'm not sure why I don't get that re-building - perhaps because my "fix"
was to copy the test executables up one level (leaving the originals in
the '.libs' folder) ?
t-fib_ui.c:63: GNU MP assertion failed: (__gmp_fib_table[(i)+1]) != 0
Thanks, lack of __GMP_DECLSPEC on the declaration of __gmp_fib_table
in gmp-impl.h. You can add that there if you like. The actual
mpz_fib_ui function should be fine, it's just the test program making
direct access to a non-exported variable.
Ok - I haven't tried that yet - but I will tonight and I'll let you know
in the unlikely event that there's still a problem.
However, is it a bug that the failure of that one test prevents the test
suite from proceeding to build (and run) the mpq and mpf and mpfr test
I'm not personally perturbed by these bugs, btw. GMP, as it stands, is a
credit to its authors - but if the build on MSYS/MinGW can be made to
proceed more smoothly, then so much the better imo :-)
Any emails containing attachments will be deleted from my ISP's mail
server before I even get to see them. If you wish to email me an
attachment, please provide advance warning so that I can make the