OK, using File::Spec->devnull was just cosmetics hiding the error message.
Show quoted text

> b) What is `uname -m` on strawberry?
>
>

Well, strawberry itself does not have uname at all, quite often people
(like me) have installed uname from gnuwin32 which returns:
i686-pc
One more comment on strawberry's $Config{myuname}
- before Oct2009 is $Config{myuname}empty
- since Oct2009 release contains:
Win32 strawberryperl 5.10.1.0 #1 30 i386
--
kmx

> It'll work much better if I know which changes are needed, and which
> are cosmetic. For example, why --binary on patch? Is prompt()
> actually needed, and why?
>
>

a) absolutely crucial is "patch-part"
- on Win32 the command separator is not ";" but "&"
- patch option --binary is necessary for win32 patch to correctly
process a *.patch file with
UNIX-like newlines (= <LF>); without this option it fails as it
expects <CR><LF> newlines
- without applying patches the module is not installed correctly on Win32
b) as for the "prompt-part"
- using prompt is AFAIK the recommended best-practice for cpan install
scripts
- your old code will ignore for example setting PERL_MM_USE_DEFAULT=1
- your old code will fail with most automated testing scripts as it has
not a reasonable default
Show quoted text

>> Well, strawberry itself does not have uname at all, quite often people
>> (like me) have installed uname from gnuwin32 which returns:
>> i686-pc
>>

Hmm, sounds like a misnomer. Without "binary mode", it should read in
text mode, so do not care about line endings... Maybe there is --text option?
Using --binary is a very dangerous choice. What if untar/unzip
extracts with conversion of newlines?
Show quoted text

> - without applying patches the module is not installed correctly on Win32

In which way?
Show quoted text

> b) as for the "prompt-part"
> - using prompt is AFAIK the recommended best-practice for cpan install
> scripts
> - your old code will ignore for example setting PERL_MM_USE_DEFAULT=1

Note the version 2.010805 and later... (Current one is 2.01080603)
Show quoted text

> - your old code will fail with most automated testing scripts as it has
> not a reasonable default

Not as experience shows... (At least from 2.010802)
Show quoted text

> Not part of my patch but you can test e.g. if $machine variable contains
> "Win32"

I already know this from $^O...
Show quoted text

> or you can test RE match $Config{myuname} =~ /strawberryperl.*?i386/

I would probably test for SPACE whatever86 if `uname -m` fails...
Thanks,
Ilya

> Hmm, sounds like a misnomer. Without "binary mode", it should read in
> text mode, so do not care about line endings... Maybe there is --text option?
>

Unfortunately no --text option. It seems to be a feature of patch on
Win32 system.
Show quoted text

>> - without applying patches the module is not installed correctly on Win32
>>

> In which way?
>

Apart from the errors when trying to run "uname" or "patch" I thought
that there were some failing tests; but I have ran the installation
again right now and it seems to install ok with all tests passed.
So perhaps all this RT was not necessary :(
--
kmx

Could you check how 2.01080603 behaves? It is supposed to be better
than what your patches did... Could you also check it with option
version23_ok=1
to Makefile.PL (in a separate build directory)?
Thanks,
Ilya

> Could you check how 2.01080603 behaves? It is supposed to be better
> than what your patches did...

Unfortunately the install attempt ends like this:
Looking for patches for 2.1.7...
Patching...
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|--- utils/inc.h Tue Sep 25 07:17:18 2001
|+++ utils/inc.h1 Thu Dec 10 16:44:36 2009
--------------------------
File to patch:
There is probably missing -p1 option when calling patch on Win32.
--
kmx

Aha! Thanks for the suggestion. Could you manually add -p1 to line
510 of utils/Math/PariBuild.pm? I suspect one needs also to add ./ to
file names inside utils/inc_h.diff ...
Could you report?
Thanks,
Ilya

This is very surprising! I thought that cmd.exe treated / as "a
zero-length argument separator"...
Is it documented/mentioned somewhere that slashes may be used in
redirection filenames? From when?
Thanks,
Ilya

> Aha! Thanks for the suggestion. Could you manually add -p1 to line
> 510 of utils/Math/PariBuild.pm? I suspect one needs also to add ./ to
> file names inside utils/inc_h.diff ...
>

It is necessary to make the following change:
- system "$patch --binary < $p"
+ system "$patch -p0 --binary < $p"
After that Math-Pari-2.01080603 installs fine on Win32.
PLEASE, consider using standard prompt function for user interaction as
the current version does not comply with best-practice.
See http://www.perlfoundation.org/perl5/index.cgi?cpan_packaging
(section "Use prompt() for build interaction.").
--
kmx

> This is very surprising! I thought that cmd.exe treated / as "a
> zero-length argument separator"...
>
> Is it documented/mentioned somewhere that slashes may be used in
> redirection filenames? From when?

> > This is very surprising! I thought that cmd.exe treated / as "a
> > zero-length argument separator"...
> >
> > Is it documented/mentioned somewhere that slashes may be used in
> > redirection filenames? From when?

IIRC, there are exactly 2 posts which describe BOTH the behaviour and
the version of the OS/shell... I would say the discussion is pretty
useless... (And it concentrates on chdir - which is an internal
command - not on redirection applied to an arbitrary program.)
Thanks anyway,
Ilya

I have dome more testing with the new gcc toolchain we (strawberry perl project) are about to use with upcoming perl 5.12. This new toolchain is based on gcc-4.4.3 compiler and C runtime libraries provided by mingw-w64 project (they deliver both 32-bit/64-bit runtimes).

It turned out that there are some additional issues that need to be handled in order to support MS Windows platform with the old gcc3 toolchain (by mingw.org project) as well as the new gcc4 toolchain (by mingw-w64.sf.net project).

IMPORTANT: I am trying to fix just issues concerning 32-bit MS Windows. With the enclosed patch I am able to compile your module also on 64-bit platform but the bunch of warnings indicates that libpari-2.1.7 does not have proper 64-bit support for MS Windows. After fixing Windows 32bit support we can open a new RT on Windows 64bit support.

So what needs to be patched:

1) missing patch option -p0 discussed above

2) I have added 32bit MS Windows detection in this way
... if ($Config{archname} eq 'MSWin32-x86-multi-thread' or $Config{cc} =~ /gcc/)

3) The patch for pari-2.1.7 was necessary - I have added patches/diff_2.1.7_mingw-w64
The fixed problems mostly concern colisions between pari macros and windows.h macros + an issue with using small as variable name (I have not investigated why but it seems like "small" is gcc4 keyword or macro included from some header). Anyway I have set this new patch to conditionally apply only on MSWin32.

> 3) The patch for pari-2.1.7 was necessary - I have added
> patches/diff_2.1.7_mingw-w64
> The fixed problems mostly concern colisions between pari macros and windows.h
> macros + an issue with using small as variable name (I have not investigated
> why but it seems like "small" is gcc4 keyword or macro included from some
> header). Anyway I have set this new patch to conditionally apply only on
> MSWin32.

Should not this `small' issue be reported to mingw team?
[use options -E -dD of compiler to find where things are introduced]
Show quoted text

> Should not this `small' issue be reported to mingw team?
>
> [use options -E -dD of compiler to find where things are introduced]

It turned out that small definition that causes the collision comes from <windows.h>

The solution I have tested on small test case is to define
#define WIN32_LEAN_AND_MEAN
before including <windows.h>

However the problem may occur when somebody includes <windows.h> before <pari.h> without defining WIN32_LEAN_AND_MEAN.

The other problem also occur when somebody includes <pari.h> after <windows.h> as pari.h defines some macros like lpsi which breaks <windows.h> (this was the reason why I have included <windows.h> at the beginning of <pari.h> at the point when these conflicting macros were not defined yet).

So not easy to fix.

Show quoted text

> Can it be corrected in Perl's headers as well? I reported it (maybe
> even several times) with no effect...

Hmmm, you are right. I have just mechanically satisfied the warning. Have you asked at perl5portes mailing list?

OK. I just got pointed to this (kmx has been acting on my behalf, as
Math::Pari is important enough to Strawberry's functionality [it's
needed for what I call the "crypto toolchain", IIRC, as well as a few
other things]) that not having it be able to build is a blocker to us,
and he's been the one working with the mingw64/gcc4 toolchain getting
things shaken out so that when perl 5.12.0 happens, we can release both
32 and 64-bit versions of Strawberry Perl.
1. Because you do not use prompt() (at least, that's what I see in the
earlier messages - that may have changed), we need to precompile a .par
with a half-built version, and then run the full build again, whenever
Strawberry wants to support a new major version of Perl, a different
compiler, or include a new version of Math::Pari. (We can't have
interaction when we do our builds, but we CAN pass parameters to the
Makefile.PL.)
This is tedious, but it's a "one-time" thing. The problem with that is
that it is easily forgotten about.
If you use prompt(), we can set the appropriate environment variable and
Makefile.PL options and go our merry way, and we don't have to remember
to build a new .par, we could just use our normal build process and
Math::Pari will automatically be up-to-date as of the build date/time of
the mirror we use to build Strawberry.
2. As for patch.exe needing --binary - my assumption is that anything
that is not CRLF-ended is considered "binary", and we're stuck with it. :(
3. #define WIN32_LEAN_AND_MEAN - I remember that from my bouts of C and
C++ programming, and it's so highly recommended by Microsoft (it's
defined by default when you create a VC++ application or dll) as to be
almost a default, for exactly the reasons kmx has illustrated
(conflicting definitions without it).
If there are any particular problems with the patches kmx has submitted,
and you have suggestions about different implementations, please let us
know and we'll create new ones that we can use.
I'm just starting to look into this myself - I've just starred this so
it's on my watch list. Will keep in touch.

I have one correction to the earlier patches:
+ } elsif ($Config{archname} eq 'MSWin32-x86-multi-thread' or
$Config{cc} =~ /gcc/) {
+ $machine = 'ix86';
That "or", I think, needs to be an "and". (GCC does not only run on x86
machines.)

Also, kmx: will just applying #define WIN32_LEAN_AND_MEAN in the
appropriate place make the patches for pari-2.1.7 much less intrusive? I
think that's what I, at least, (I can't speak for Ilya) would prefer to
see, if that's possible.

> Queue: Math-Pari
> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=52146 >
>
> OK. I just got pointed to this (kmx has been acting on my behalf, as
> Math::Pari is important enough to Strawberry's functionality [it's
> needed for what I call the "crypto toolchain", IIRC, as well as a few
> other things]) that not having it be able to build is a blocker to us,
> and he's been the one working with the mingw64/gcc4 toolchain getting
> things shaken out so that when perl 5.12.0 happens, we can release both
> 32 and 64-bit versions of Strawberry Perl.
>
> 1. Because you do not use prompt() (at least, that's what I see in the
> earlier messages - that may have changed), we need to precompile a .par
> with a half-built version, and then run the full build again, whenever
> Strawberry wants to support a new major version of Perl, a different
> compiler, or include a new version of Math::Pari. (We can't have
> interaction when we do our builds, but we CAN pass parameters to the
> Makefile.PL.)
>
> This is tedious, but it's a "one-time" thing. The problem with that is
> that it is easily forgotten about.
>
> If you use prompt(), we can set the appropriate environment variable and
> Makefile.PL options and go our merry way, and we don't have to remember
> to build a new .par, we could just use our normal build process and
> Math::Pari will automatically be up-to-date as of the build date/time of
> the mirror we use to build Strawberry.

Irrelevant nowadays, I believe.
The rest is in my queue.
Ilya
P.S. I got a 64-bit assember enabler patch for x86 (for 2.3.*).
Attached. Testing and feedback is appreciated.

According to pari-2.3.5/CHANGES-2.2 the patch should work beginning with
version 2.2.8, but the earliest I could find on
http://pari.math.u-bordeaux.fr/pub/pari/unix/ was 2.3.0. So please take
this as a warning that something could break. But I don't expect this
to happen.
Thank you very much for this excellent module,
Alexander
Ilya Zakharevich <ilya@math.berkeley.edu> writes:
Show quoted text

> For best result, could you also send me results of
>
> diff -pu old_file new_file
>
> for these edits?

> If you use prompt(), we can set the appropriate environment variable and
> Makefile.PL options and go our merry way, and we don't have to remember
> to build a new .par, we could just use our normal build process and
> Math::Pari will automatically be up-to-date as of the build date/time of
> the mirror we use to build Strawberry.
>

AFAIK Math::Pari handles env variables AUTOMATED_TESTING +
PERL_MM_USE_DEFAULT itself which I also do not consider a good idea (as
you can see from my previous posts :) but it works.
Show quoted text

> 2. As for patch.exe needing --binary - my assumption is that anything
> that is not CRLF-ended is considered "binary", and we're stuck with it. :(
>

For this we have used in Alien::SDL the following platform independent
trick:
$patch_file = ......;
system("$^X -pe '' -- $patch_file | patch -N -p1 -u");
Just an idea, of course you might not like it.
Show quoted text

To be honest I am not the author of that idea, but you are right, your suggestion seems better.

Anyway WHAT IS IMPORTANT - I have finally prepared the smallest possible patch for Math-Pari-2.01080603 to work with both:
1/ 32bit gcc3 toolchain by mingw.org
2/ 32bit gcc4 toolchain by mingw-w64.sf.net

See attached Math-Pari-2.01080603_kmx.patch + releasing it on CPAN.

Please, please consider accepting this patch

The patch is soo simple & clear & nice that I cannot imagine a better one :)

Unfortunately bad news as for 64bit MS Windows. When tried to compile on this platform (64bit gcc4 toolchain from mingw-w64.sf.net) i got more that 2000 (two thousand) warnings like:
- warning: cast to pointer from integer of different size
- warning: cast from pointer to integer of differ

The point is that on 64bit MS Windows there is:
- size of int = 4 bytes (!!!)
- size of *void = 8 bytes

So casting between integer and pointer is not generally safe.

In the end math::Pari compiles however nearly all tests end with perl.exe crash.

> Unfortunately bad news as for 64bit MS Windows. When tried to compile
> on this
> platform (64bit gcc4 toolchain from mingw-w64.sf.net) i got more that
> 2000 (two
> thousand) warnings like:
> - warning: cast to pointer from integer of different size
> - warning: cast from pointer to integer of differ

A little incestuous, maybe, but is there a __int64 type (or something of
the like, I'm not looking at a C reference as I'm typing, and its 0600
here) that we could #ifdef 'int' to in 64-bit builds?
[on side note: 64-bit may have to STAY in beta through April 2009
release cycle.]

> Anyway WHAT IS IMPORTANT - I have finally prepared the smallest possible patch
> for Math-Pari-2.01080603 to work with both:
> 1/ 32bit gcc3 toolchain by mingw.org
> 2/ 32bit gcc4 toolchain by mingw-w64.sf.net
>
> See attached Math-Pari-2.01080603_kmx.patch + releasing it on CPAN.

A lot of thanks. Included (slightly modded) in
Math-Pari-2.01080604.tar.gz.
Please test.
Yours,
Ilya

In email discussion with Ilya and browsing the module code, it looks like these patches were all applied long ago.
There is a more fundamental problem with the pari library code involving 64-bit compiler differences with integer / pointer sizes and indiscriminate type casting.
In newer versions of the pari library (see URLref: http://megrez.math.u-bordeaux.fr), they seem to be addressing some 64-bit issues (at least, there's some 64-bit specific code). But, as it's autoconf based, it's complicated to get the library to build under Windows/gcc-mingw. And I've been unable to accomplish a build.
Once a successful build/test of the original pari library code is accomplished within Windows/gcc-mingw (64-bit), patches to this module might succeed. But I doubt it'll ever happen unless that is done first.

But
sizeof( long long) = sizeof(void*)
==
Problem:
==
The point is that on 64bit MS Windows there is:
- size of int = 4 bytes (!!!)
- size of *void = 8 bytes
==
May be solution:
==
. . .
+#define PARITEMPL_O_NG(x) (x##LL)
+#define PARITEMPUL_O_NG(x) (x##ULL)
+typedef long long paritemplong_t;
+
+typedef long long mp_l_o_ng;
+typedef unsigned long long mp_ul_o_ng;
. . .
==
http://pari.math.u-bordeaux.fr/archives/pari-dev-0907/msg00003.html
=}
===
From: Jason Moxham
...
I've got Pari-svn running on Windows with/without GMP/MPIR in 64bit mode. This
is with MSVC , and when MinGW/MSYS goes 64bit it will work with that :)
The main problem with Windows64 is that it uses a LLP data model rather than
the usual LP data model , this means that long's are 32 bit. I'm doing this
for the Sage project but it would be nice if the changes could be
incorporated back into Pari , so I propose this.
Introduce a new type and macro ( with signed and unsigned versions)
typedef long paritemplong_t;
#define PARITEMPLONG(x) (x##L)
replace all occurances of long with paritemplong_t and numberL with
PARITEMPLONG(number)
The above is all just simple text replacement and although it means changes to
every file it will have no "real" changes.
Then for WIN64 only we change the definition
typedef long long paritemplong_t;
#define PARITEMPLONG(x) (x##LL)
...
===
+
==
. . .
On Mon, Nov 04, 2002 at 08:07:31PM +0100, Bill Allombert wrote:
Show quoted text

> On Fri, Nov 01, 2002 at 12:13:16AM -0800, Ilya Zakharevich wrote:

> > On which architectures can PARI run with sizeof(long) > sizeof(long*)?
> > I tested, and it does not work on x86.

>
> None, as far as I know.
> None of the 11 architectures I have access to exhibit this behaviour.