Re: 'make check' on Win 2k

[Sisyphus]

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 :-)

Cheers,
Rob

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