[Top][All Lists]

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

Re: 2 of 3 tests in 'misc' fail on Win32, MSYS, MinGW

From: Sisyphus
Subject: Re: 2 of 3 tests in 'misc' fail on Win32, MSYS, MinGW
Date: Fri, 29 Oct 2004 12:15:24 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

Sisyphus wrote:
Sisyphus wrote:

Using Windows 2000, MinGW compiler in the MSYS shell.
Running the test/misc tests, 't-locale' passes (skipped, actually ... I think), but both 't-printf' and 't-scanf' fail with "abnormal program termination". When I run those 2 executables in a cmd.exe shell I get the additional information, wrt 't-printf.exe.':

doprnt.c:421: GNU MP assertion failed: intmax_t not available

and wrt 't_scanf.exe':

doscan.c:616: GNU MP assertion failed: intmax_t not available

I'm a little mystified as to why 'intmax_t' is deemed to be unavailable. It's typedef'd as a 'long long' in 'stdint.h' (which, in turn, is included on 'inttypes.h').

Is it just that 'HAVE_INTMAX_T' is untrue ... for some reason ?

doprnt.c contains the following (transcribed, and prefixed with the line number):

418: #if HAVE_INTMAX_T
419: case 'j': * (intmax_t *) p = retval;break;
420: #else
421: case 'j': ASSERT_FAIL (intmax_t not available); break;

That would imply to me that HAVE_INTMAX_T is indeed untrue - but config.h, which is included in doprnt.c, clearly states:

#define HAVE_INTMAX_T 1

So line 421 of doprnt.c should have been pre-processed into oblivion, shouldn't it ? (This is why I generally try to avoid digging around in the source code :-)

The behaviour of gcc on Win32 wrt printf() of "long long" values is a little surprising. The conversion specifier 'll' is not understood. Instead you have to use 'I64' (which is the M$ way of specifying a "long long") - apparently because printf() is a msvc-runtime function, and therefore uses 'I64' instead of 'll' ... or something like that. I mention this in case it's somehow accounts for the error.

Sorry - failed to mention that I configured with:

./configure --disable-static --enable-shared

Problems so far presented have been on my Pentium-3 desktop. In addition to the PIII desktop, I have an old PII laptop which has the same versions of MSYS, MinGW, and Windows 2000. There are some differences between the 2 operating systems in that the desktop has had some service packs and updates added, whereas the old laptop hasn't. Surprisingly, the 2 'rand' tests that fail (on the desktop) pass when I build gmp-4.1.4 on the laptop - but the 'rand' test 't-lc2exp' (which is fine on the desktop) fails on the laptop. It produces:

randraw.c:144: GNU MP assertion failed: m2exp / (32 - 0) < ta

followed by 'abnormal program termination'.

(I don't personally have any need for the bugs affecting the laptop to be fixed ... I mention it merely because it all seems rather strange.)

Another thing I have just done is to build a static GMP (on the PIII desktop only) by running simply './configure'. When I do this, all of the tests pass. Not only that, but the test executables get built in the *correct* location. With the dynamic build, the test executables get built in the '.libs' sub-directory - which I overcome by copying them one level higher and re-running 'make check'.

I probably don't need a dynamic build of GMP (though it's what I have been using). Do we want to *not* bother about this ? .... or should we persevere and get the dynamic build process on Win32 working properly ?

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]