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/