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

[Sisyphus]

Sisyphus wrote:
> Sisyphus wrote:
>
> > Hi,
> > 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.