[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'make check' on Win 2k

From: Sisyphus
Subject: Re: 'make check' on Win 2k
Date: Mon, 05 Jan 2004 22:15:25 +1100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

Kevin Ryde wrote:
Sisyphus <address@hidden> writes:

FAIL: t-bswap.exe
/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.

'make check'
proceeds to build the 5 mpn test executables, again in the wrong
directory ('tests/mpn/.libs').

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
FAIL: t-fib_ui.exe

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 executables ?

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 necessary arrangements.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]