Karim BELABAS on Sat, 6 Apr 2002 14:34:02 +0200 (MEST)


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

Re: Problems with pari compiled in MSVC under Windows


On Mon, 1 Apr 2002, Ignat Soroko wrote:
> I downloaded files
> pari-2.1.3.tar
> pari-2.2.2.tar
> from pari homepage and wanted to compile them in MSVC under Windows.
> I had made two attempts:
>
> 1. trying to compile pari-2.1.3.tar version in MSVC++ 5.0 under Windows 95
> 2. trying to compile pari-2.2.2.tar version in MSVC++ 6.0 under Windows 2000
>
> I tried to follow directions of Bill Daly written in Odos\readme.msvc.

It's a long time since somebody attempted to compile natively for Windows.
Thanks for the detailed feedback, I will try to update the relevant files.

> Here is some problems I encountered:
>
> 1. compiler gives many errors
> fatal error C1083: Cannot open include file: 'paricfg.h'
> I added one more additional directory C:\pari222\Odos to
> "Preprocessor" menu, and this problem seems to have gone.

README.MSVC mentioned \win32 which is gone and has to be replaced by \Odos,
as you did.

> 2(pari-2.2.2). compiler gives an error
> C:\Pari222\src\language\es.c(2291) : fatal error C1083: Cannot
> open include file: 'dirent.h': No such file or directory:
>
> #ifdef HAS_OPENDIR
> #  include <dirent.h>
> #endif
>
> I found out, that HAS_OPENDIR is defined only in file paricfg.h
> in lines:
>  /* comment this one if not on NT ??? */
> #  define HAS_OPENDIR
>
> After I commented out this line, all compiled and linked at last.

HAS_OPENDIR enables a (bad) workaround for a minor problem. It doesn't
hurt to remove it. I'll make it the default on DOS/Windows [ comment it out ]

> 2(pari-2.1.3). compiler gives an error
> C:\pari213\src\kernel\ix86\l0asm.c(78) : error C2282: 'ulong' is
> followed by 'overflow' (missing ','?)
> I couldn't think out nothing better than to replace 'ulong' by
> 'unsigned long'. After that the mistake disappeared.

This was reported and fixed by Bill Daly, and committed to the unstable branch
on 2001/03/12 (l0asm.c revision 1.4, pari-2.2.0)

I forgot to backport this to the stable version [ I usually don't backport
things which I cannot test, esp. in the 'kernel' section. But here, it was an
obvious typo. ]

> Now the program is compiled and I am going to calculate some
> Galois groups.
>
> ? polgalois(x^4+x-1)
>   ***   exponent too large in exp.
>
> This behaviuor takes place in both versions 2.1.3 and 2.2.2.
> What can be advised in order to make it work?

Edit paricfg.h, and replace the line

  #define PARI_BYTE_ORDER 1234

by

  #define PARI_DOUBLE_FORMAT 1

The former described endianness, which is irrelevant for PARI, the latter
determines the internal representation of the 'double' type which we do need
(conversion between C 'double' type and PARI 't_REAL'). For some reason, the
endianness was successfully used for the latter purpose, until the scheme
broke down when PARI was ported to the ARM processor.

So I changed the Configure test, and PARI_BYTE_ORDER is now unused. I forgot
to update the MSVC headers when making that change [ which is always painful
in any case since I can't test them, and it's the only environment not
catered for by 'Configure' ]. Hence the conversion from 'double' to the
't_REAL' PARI type does not work.

Please check that this solves your problem [ if not, try
#define PARI_DOUBLE_FORMAT 0, but I strongly doubt this would be the correct
value ]

Hope this helps,

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas
--
PARI/GP Home Page: http://www.parigp-home.de/