[Pdl-porters] Compilation errors on Windows x64

[Christian Walde]

Hey guys,

I recently started smoking 64 bit Perl on windows, and PDL is giving me a
bunch of compilations errors. Can you please inspect these and see if you
can do anything about them?

http://paste.scsys.co.uk/271000

[s***@optusnet.com.au]

Hi Christian,

Something weird happening there, for sure.

Some problem with your CCFLAGS, maybe - they look a bit like ActivePerl
CCFLAGS.
If you're using 64-bit ActivePerl, I wouldn't think you'd get *any* perl
extension to build using 64-bit gcc.

What does 'perl -V:make' report ? (

[Christian Walde]

-----Original Message----- From: Christian Walde

Post by Christian Walde
I recently started smoking 64 bit Perl on windows, and PDL is giving me a
bunch of compilations errors. Can you please inspect these and see if you
can do anything about them?
http://paste.scsys.co.uk/271000

Some problem with your CCFLAGS, maybe - they look a bit like ActivePerl
CCFLAGS.

It is ActivePerl.

If you're using 64-bit ActivePerl, I wouldn't think you'd get *any* perl
extension to build using 64-bit gcc.

I'm sure there's a bunch of XS modules among those:

https://gist.github.com/wchristian/747ae018d8d970115a2b

What does 'perl -V:make' report ? (

[Chris Marshall]

It looks like something with the new PDL_Indx types.
For some reason the PDL_Indx is not being declared.

--Chris

On Tue, Oct 8, 2013 at 5:43 AM, Christian Walde

Post by Christian Walde

-----Original Message----- From: Christian Walde

Post by Christian Walde
I recently started smoking 64 bit Perl on windows, and PDL is giving me a
bunch of compilations errors. Can you please inspect these and see if you
can do anything about them?
http://paste.scsys.co.uk/271000

Some problem with your CCFLAGS, maybe - they look a bit like ActivePerl
CCFLAGS.

It is ActivePerl.

If you're using 64-bit ActivePerl, I wouldn't think you'd get *any* perl
extension to build using 64-bit gcc.

https://gist.github.com/wchristian/747ae018d8d970115a2b

What does 'perl -V:make' report ? (

[Chris Marshall]

PDL_Indx is generated at config time and the declaration
is in the generated pdl.h file. E.g., on my cygwin system
I have this:

/*** This section of .h file generated automatically - don't edit manually ***/

/* Data types/sizes [must be in order of complexity] */

enum pdl_datatypes { PDL_B, PDL_S, PDL_US, PDL_L, PDL_IND, PDL_LL,
PDL_F, PDL_D };

/* Define the pdl data types */

typedef unsigned char PDL_Byte;
typedef short PDL_Short;
typedef unsigned short PDL_Ushort;
typedef int PDL_Long;
typedef long long PDL_Indx;
typedef long long PDL_LongLong;
typedef float PDL_Float;
typedef double PDL_Double;

/* typedef long long PDL_Indx; */

While for a 32bit SPP I get this:

/*** This section of .h file generated automatically - don't edit manually ***/

/* Data types/sizes [must be in order of complexity] */

enum pdl_datatypes { PDL_B, PDL_S, PDL_US, PDL_L, PDL_IND, PDL_LL,
PDL_F, PDL_D };

/* Define the pdl data types */

typedef unsigned char PDL_Byte;
typedef short PDL_Short;
typedef unsigned short PDL_Ushort;
typedef int PDL_Long;
typedef long PDL_Indx;
typedef long long PDL_LongLong;
typedef float PDL_Float;
typedef double PDL_Double;

Post by Chris Marshall
It looks like something with the new PDL_Indx types.
For some reason the PDL_Indx is not being declared.
--Chris
On Tue, Oct 8, 2013 at 5:43 AM, Christian Walde

Post by Christian Walde

-----Original Message----- From: Christian Walde

Post by Christian Walde
I recently started smoking 64 bit Perl on windows, and PDL is giving me a
bunch of compilations errors. Can you please inspect these and see if you
can do anything about them?
http://paste.scsys.co.uk/271000

Some problem with your CCFLAGS, maybe - they look a bit like ActivePerl
CCFLAGS.

It is ActivePerl.

If you're using 64-bit ActivePerl, I wouldn't think you'd get *any* perl
extension to build using 64-bit gcc.

https://gist.github.com/wchristian/747ae018d8d970115a2b

What does 'perl -V:make' report ? (

[Christian Walde]

On Tue, 08 Oct 2013 13:01:15 +0200, Chris Marshall

Post by Chris Marshall
On Tue, Oct 8, 2013 at 5:43 AM, Christian Walde

Post by Christian Walde

-----Original Message----- From: Christian Walde

Post by Christian Walde
I recently started smoking 64 bit Perl on windows, and PDL is giving
me a bunch of compilations errors. Can you please inspect these and
see if you can do anything about them?
http://paste.scsys.co.uk/271000

Some problem with your CCFLAGS, maybe - they look a bit like
ActivePerl CCFLAGS.

It is ActivePerl.

If you're using 64-bit ActivePerl, I wouldn't think you'd get *any*
perl extension to build using 64-bit gcc.

https://gist.github.com/wchristian/747ae018d8d970115a2b

What does 'perl -V:make' report ? (

[s***@optusnet.com.au]

-----Original Message-----
From: Christian Walde

Post by unknown
Probably best to show us show us your entire 'perl -V'.

Sure: https://gist.github.com/wchristian/9340269b0baba6cec1a6

Ok .. I can sort of reproduce the problem.

I have AS 5.16.0 (x64) and can use gcc-4.7.0 and dmake with it.

The first errors I get are:

In file included from pdlcore.c:8:0:
pdl.h:47:1: error: unknown type name '__int64'
pdl.h:73:4: error: unknown type name '__int64'
pdl.h:74:4: error: unknown type name '__int64'
dmake.exe: Error code 129, while making 'pdlcore.o'
dmake.exe: Error code 255, while making 'subdirs'
dmake: Error code 255, while making 'subdirs'

Compare that to your:

In file included from pdlcore.c:8:0:
pdl.h:47:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'PDL_Indx'
pdl.h:73:4: error: expected specifier-qualifier-list before '__int64'

and I think we're both being hit by some incapacity of our gcc compilers to
handle the '__int64' type ... which is very strange, because the MinGW ports
of gcc know damned well what an __int64 is.

I don't yet have an explanation for why our MinGW compilers would *not*
happily handle the __int64 type.
Do you have any idea why that might be ?

Cheers,
Rob

[Christian Walde]

-----Original Message----- From: Christian Walde

Post by unknown
Probably best to show us show us your entire 'perl -V'.

Sure: https://gist.github.com/wchristian/9340269b0baba6cec1a6

Ok .. I can sort of reproduce the problem.
I have AS 5.16.0 (x64) and can use gcc-4.7.0 and dmake with it.
pdl.h:47:1: error: unknown type name '__int64'
pdl.h:73:4: error: unknown type name '__int64'
pdl.h:74:4: error: unknown type name '__int64'
dmake.exe: Error code 129, while making 'pdlcore.o'
dmake.exe: Error code 255, while making 'subdirs'
dmake: Error code 255, while making 'subdirs'
pdl.h:47:30: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'PDL_Indx'
pdl.h:73:4: error: expected specifier-qualifier-list before '__int64'
and I think we're both being hit by some incapacity of our gcc compilers
to handle the '__int64' type ... which is very strange, because the
MinGW ports of gcc know damned well what an __int64 is.
I don't yet have an explanation for why our MinGW compilers would *not*
happily handle the __int64 type.
Do you have any idea why that might be ?

I'm not a C developer, so this eludes me mostly. However, at a guess i'd
think it might be caused by my gcc being old.

I don't us a custom gcc, but instead use what's installed by ActivePerl
when i run cpan and it cannot find a compiler, since that's what the
average user will have.

[s***@optusnet.com.au]

-----Original Message-----
From: Christian Walde

Post by Christian Walde

Post by s***@optusnet.com.au
I don't yet have an explanation for why our MinGW compilers would *not*
happily handle the __int64 type.
Do you have any idea why that might be ?

I'm not a C developer, so this eludes me mostly. However, at a guess i'd
think it might be caused by my gcc being old.

I think you're compiler would know what the __int64 type is.
Try this C script:

#include <stdio.h>

int main(void) {
__int64 x = 42;
printf("OK\n");
return 0;
}

No problems with that for me, and I think you'll find the same.

Only thing I can think of is that __int64 is being undeffed somewhere:

###############################
C:\_64\C>type try.c

#include <stdio.h>

#undef __int64

int main(void) {

__int64 x = 17;
printf("OK\n");
return 0;
}


C:\_64\C>gcc -o try.exe try.c
try.c: In function 'main':
try.c:8:3: error: unknown type name '__int64'

C:\_64\C>
###############################

What error do *you* get when you try to build that second version of the C
script ?
Is it anything like what you got when building PDL, or is it the "unknown
type name" error that I get ?

An approach that might work for you:

Currently, 'perl -V:ivtype' returns '__int64'.
Let's change that to "long long".

In lib/ActivePerl/Config.pm, a few lines down from the top of the file,
there's a list of %Config keys (in %COMPILER_ENV):

cc
ccflags
cccdlflags
ccname
ccversion
gccversion
ar
....
[snip]
....
i64type
u64type
quadtype
uquadtype
d_casti32

Add 'ivtype' to the bottom of that list (immediately below 'd_casti32').

In the same file, look for the line:

_override("d_casti32", "define");

and immediately below that line add:

_override("ivtype", "long long");

Save those changes - and 'perl -V:ivtype' should now report 'long long'.

Now try building PDL-2.006_91 again. That now works fine for me ... until I
get to the OpenGL stuff. But if you don't have OpenGL installed then you
might be right.
My problem there is that the build knows that I have OpenGL installed, but
it's not attempting to link to the freeglut library ... hence a large number
of "undefined references". (I'll try to sort that out.)

I've also had to jump some hoops on 5.16.0 in order to dodge the
bufferoverflowU.lib bullet - but that might already have been handled
correctly for you in 5.16.3.

Anyway ... let us know how you go with that.
I can't think of any reason that 'ivtype' should need to remain as
'__int64', but I can't guarantee that changing it to "long long" won't bite
back at some point in the future.
It would probably be better if we could figure out what's killing MinGW's
awareness of the __int64 type and fix that.

Cheers,
Rob

[Christian Walde]

Post by s***@optusnet.com.au
[snip]

I intend to try all those things out as soon as i have a minute for it. In
the meantime however i'd like to point out that DBI also fails, by way of
compiling "successfully", but segfaulting, for example when
`PerlIO_open("nul","a+");` ends up being called near the end of
t/01basic.t:

https://gist.github.com/wchristian/01be85f8f47106c6f1e8

Further, your very own Inline::C is very unhappy about the situation too:

https://gist.github.com/wchristian/a91b4b4b3788bd07f9d7

[s***@optusnet.com.au]

-----Original Message-----
From: Christian Walde
Sent: Wednesday, October 09, 2013 4:03 AM
To: pdl-porters ; ***@optusnet.com.au
Subject: Re: [Pdl-porters] Compilation errors on Windows x64

Post by s***@optusnet.com.au
[snip]
I intend to try all those things out as soon as i have a minute for it.

Those amendments to lib/ActivePerl/Config.pm should enable the build to
succeed.
The problem I have with PDL's OpenGL interface is that the OpenGL I'm using
was built using a Microsoft compiler.
That problem should disappear if I replace that OpenGL with one built using
the MinGW compiler.

If I remove (or hide) OpenGL, then the build succeeds - though there are
some test failures which I'll look at more closely tonight.
Please let us know how it fares for you when you get the chance.

I'll also try to find (and fix) what's messing with __int64, because it
shouldn't be necessary to hack at lib/ActivePerl/Config.pm like I did.

Post by s***@optusnet.com.au
https://gist.github.com/wchristian/a91b4b4b3788bd07f9d7

I can reproduce that, too - so I'll have a good look at that later on when I
get the chance.
It's crashing when some very basic, well tested, tried and true Inline::C
code gets executed - and the crash goes away if I turn off the "_TESTING"
config option. (Of course, some tests then fail because they rely on
"_TESTING" having been set.)

[Christian Walde]

Post by s***@optusnet.com.au
No problems with that for me, and I think you'll find the same.

Yep.

Post by s***@optusnet.com.au
What error do *you* get when you try to build that second version of the
C script ?

This:

try.c: In function 'main':
try.c:7:2: error: '__int64' undeclared (first use in this function)
try.c:7:2: note: each undeclared identifier is reported only once for each
function it appears in
try.c:7:10: error: expected ';' before 'x'

Further info on my gcc:

c:\Users\Mithaldu\.cpanm\work\1381234762.1864\DBI-1.628>where gcc
c:\Perl1664\site\bin\gcc.exe

c:\Users\Mithaldu\.cpanm\work\1381234762.1864\DBI-1.628>gcc --version
gcc.exe (rubenvb-4.5.4) 4.5.4
Copyright (C) 2010 Free Software Foundation, Inc.

Post by s***@optusnet.com.au
Save those changes - and 'perl -V:ivtype' should now report 'long long'.

Yes, it does.

Post by s***@optusnet.com.au
Now try building PDL-2.006_91 again. That now works fine for me ...

That builds now and almost passes tests. :)

https://gist.github.com/wchristian/6f688634fa421207465c

Post by s***@optusnet.com.au
It would probably be better if we could figure out what's killing
MinGW's awareness of the __int64 type and fix that.

Does the difference in error message on the compile attempt up there help?

[Chris Marshall]

I thought the __int64 was for MSVC? Both my SPP perls use 'long long'
and not the windows-ism. Are we sure that the compiler that was used
to build perl (in the perl -V compiler info)is the compiler being used?
If not, that would explain things a bit.

Cheers,
Chris

@Mithaldu: take a look at PDL::GSL::RNG



On Thu, Oct 10, 2013 at 6:34 AM, Christian Walde

Post by Christian Walde

Post by s***@optusnet.com.au
No problems with that for me, and I think you'll find the same.

Yep.

Post by s***@optusnet.com.au
What error do *you* get when you try to build that second version of the C
script ?

try.c:7:2: error: '__int64' undeclared (first use in this function)
try.c:7:2: note: each undeclared identifier is reported only once for each
function it appears in
try.c:7:10: error: expected ';' before 'x'
c:\Users\Mithaldu\.cpanm\work\1381234762.1864\DBI-1.628>where gcc
c:\Perl1664\site\bin\gcc.exe
c:\Users\Mithaldu\.cpanm\work\1381234762.1864\DBI-1.628>gcc --version
gcc.exe (rubenvb-4.5.4) 4.5.4
Copyright (C) 2010 Free Software Foundation, Inc.

Post by s***@optusnet.com.au
Save those changes - and 'perl -V:ivtype' should now report 'long long'.

Yes, it does.

Post by s***@optusnet.com.au
Now try building PDL-2.006_91 again. That now works fine for me ...

That builds now and almost passes tests. :)
https://gist.github.com/wchristian/6f688634fa421207465c

Post by s***@optusnet.com.au
It would probably be better if we could figure out what's killing MinGW's
awareness of the __int64 type and fix that.

Does the difference in error message on the compile attempt up there help?
--
With regards,
Christian Walde
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[s***@optusnet.com.au]

-----Original Message-----
From: Chris Marshall
Sent: Thursday, October 10, 2013 9:45 PM
To: Christian Walde
Cc: pdl-porters ; Sisyphus
Subject: Re: [Pdl-porters] Compilation errors on Windows x64

Post by Chris Marshall
I thought the __int64 was for MSVC? Both my SPP perls use 'long long'
and not the windows-ism.

Yes, but they should also be able to accommodate __int64 because _mingw.h
has defined __int64 as 'long long'.
(I've yet to check how _mingw.h is supposed to get pulled in ... I know that
"#include <stdio.h>" is sufficient.)

Post by Chris Marshall
Are we sure that the compiler that was used
to build perl (in the perl -V compiler info)is the compiler being used?

Actually, we're sure it's *not* the same. Christian's perl (ActivePerl) was
built using a Microsoft Platform SDK compiler, but he's using MinGW.
So long as %Config gets rewritten correctly, that shouldn't matter.

I think the fact that it's not quite working is almost certainly *not* a PDL
bug.

Cheers,
Rob

[Christian Walde]

On Thu, 10 Oct 2013 12:45:14 +0200, Chris Marshall

Post by Chris Marshall
I thought the __int64 was for MSVC? Both my SPP perls use 'long long'
and not the windows-ism. Are we sure that the compiler that was used
to build perl (in the perl -V compiler info)is the compiler being used?
If not, that would explain things a bit.

I don't know if it was, but i also think that the ActivePerls are compiled
with MSVC, but all modules are compiled with MinGW unless there was a
preexisting MSVC, which it looks like sysiphus had.

Post by Chris Marshall
@Mithaldu: take a look at PDL::GSL::RNG

Yeah, i saw that, thanks. :)

[s***@optusnet.com.au]

-----Original Message-----
From: Christian Walde

Post by Christian Walde
That builds now and almost passes tests. :)
https://gist.github.com/wchristian/6f688634fa421207465c

So you've only got 3 test scripts that suffer failure:

misc.t
picnorgb.t
pnm.t

I get the same.
I also got a transform.t failure which you apparently aren't getting. (Lucky
you ;-)

The nasty part is that all 3 failures are crashes - and I'm starting to
wonder about some sort of runtime incompatibility between the compiler that
AS used and the MinGW compiler. (AFAIK, there's not supposed to be any such
incompatibilities ... but I wouldn't bet much money on that.)

All I've so far established is that the t/misc.t crash occurs when
"$b->rasc($file);" is executed.

Win32::SharedFileOpen crashes on most of its tests - and I think that
indicates that perl and MinGW are using different C runtimes. (ActivePerl
should be using msvcrt.dll ... and I thought that MinGW64 would be using the
same ..... dunno, but if they are using different runtimes and we can't get
MinGW64 to use the same runtime as perl, then I believe we're sunk !!).

BTW, to build Win32::SharedFileOpen I first changed (in the Makefile.PL):

$obj->check_compiler(1);
to
$obj->check_compiler(0);

Otherwise, it won't write a Makefile for you.

So, tonight I'm feeling not so sure that the problem (whatever it is) can be
fixed at all. I'll see what tomorrow brings.

Post by Christian Walde

Post by s***@optusnet.com.au
It would probably be better if we could figure out what's killing
MinGW's awareness of the __int64 type and fix that.

Does the difference in error message on the compile attempt up there help?

I'm back to thinking that, having changed ivtype to "long long" it's
probably simplest and best just to leave it that way - at least until a case
crops up where it really does need to be set back to "__int64".
After all, MinGW is only going to define "__int64" to "long long" anyway.

Cheers,
Rob

[Christian Walde]

Post by s***@optusnet.com.au
The nasty part is that all 3 failures are crashes - and I'm starting to
wonder about some sort of runtime incompatibility between the compiler
that AS used and the MinGW compiler. (AFAIK, there's not supposed to be
any such incompatibilities ... but I wouldn't bet much money on that.)

Why would such an incompatibility only crop up in the 64 bit version?

Post by s***@optusnet.com.au
I'm back to thinking that, having changed ivtype to "long long" it's
probably simplest and best just to leave it that way - at least until a
case crops up where it really does need to be set back to "__int64".
After all, MinGW is only going to define "__int64" to "long long" anyway.

You mean to suggest that as a bug fix to ActivePerl?

[s***@optusnet.com.au]

-----Original Message-----
From: Christian Walde
Sent: Friday, October 11, 2013 1:10 AM
To: pdl-porters ; ***@optusnet.com.au
Subject: Re: [Pdl-porters] Compilation errors on Windows x64

Post by Christian Walde

Post by s***@optusnet.com.au
The nasty part is that all 3 failures are crashes - and I'm starting to
wonder about some sort of runtime incompatibility between the compiler
that AS used and the MinGW compiler. (AFAIK, there's not supposed to be
any such incompatibilities ... but I wouldn't bet much money on that.)

Why would such an incompatibility only crop up in the 64 bit version?

Good point - hopefully it's just that we're linking to perl516.lib - which
is fine for 32-bit gcc, but not 64-bit gcc.

See:
http://sourceforge.net/apps/trac/mingw-w64/wiki/Answer%2064%20bit%20MSVC-generated%20x64%20.lib

I'm about to try the fix suggested there ... hope it works.

Post by Christian Walde
I'm back to thinking that, having changed ivtype to "long long" it's
probably simplest and best just to leave it that way - at least until a
case crops up where it really does need to be set back to "__int64".
After all, MinGW is only going to define "__int64" to "long long" anyway.

You mean to suggest that as a bug fix to ActivePerl?

Yes, I think so.
It seems to me that the MinGW knows about __int64 only if _mingw.h has been
included - and that's not guaranteed. (It's *usually* the case, but not
*always*.)
Therefore AS should not be assuming that MinGW will know what the __int64
type is.

Cheers,
Rob

[unknown]

Probably best to show us show us your entire 'perl -V'.

Cheers,
Rob



-----Original Message-----
From: Christian Walde
Sent: Tuesday, October 08, 2013 7:33 PM
To: pdl-porters
Subject: [Pdl-porters] Compilation errors on Windows x64

Hey guys,

I recently started smoking 64 bit Perl on windows, and PDL is giving me a
bunch of compilations errors. Can you please inspect these and see if you
can do anything about them?

http://paste.scsys.co.uk/271000

[s***@optusnet.com.au]

-----Original Message-----

Post by s***@optusnet.com.au
I'm about to try the fix suggested there ... hope it works.

Yep - works for me with building Inline-0.53. No t/10callback.t crash.
I'll try PDL tonight.

(I knew about this .... and would've twigged earlier if I wasn't such an
idiot.)

You'll need to _override() "libperl" - same way as we overrode ivtype.
Just check that perl-V:libperl reports "libperl516.a" (or whatever it was
that you had dlltool create.), and that the library is in lib/CORE (same
location as perl516.lib).

You'll find "gendef" and "dlltool" in x64 Strawberry Perl (among other
places). Your MinGW64 should already have dlltool .... not sure about
gendef.

Here's hoping .... ;-)

Cheers,
Rob

[s***@optusnet.com.au]

-----Original Message-----

Post by s***@optusnet.com.au
I'll try PDL tonight.

Yes, creating a libperl516.a and changing "libperl" from "perl516.lib" to
"libperl516.a" has fixed most of the PDL test failures for me.

The only one it doesn't fix is the t/transform.t failure, but I think that
is an obscure gcc bug about which I can do little.
(I keep hoping that it will one day catch the attention of someone who is
capable of fixing it ... but that hasn't happened yet.)

It's exactly the same sort of error that prevents me from building
PDL::Graphics::PLplot as part of the PDL build:

Can't load
'C:\sisyphusion\PDL-2.006_91\blib\arch/auto/PDL/Transform/Transform.dll' for
module PDL::Transform: load_file:%1 is not a valid Win32 application at
C:/_64/ap1600/lib/DynaLoader.pm line 191, <DATA> line 207.
at t/transform.t line 8.
Compilation failed in require at t/transform.t line 8, <DATA> line 207.
BEGIN failed--compilation aborted at t/transform.t line 8, <DATA> line 207.

AFAICT, there's nothing wrong with the dll in question -
Win32::LoadLibrary() can load it fine. But there's obviously something about
it that DynaLoader doesn't like.

In any case, this shouldn't affect you, Christian, as it seems that your
version of the gcc compiler does not suffer the affliction.
PDL should now build fine for you, and pass all tests.

Cheers,
Rob

[Christian Walde]

Post by s***@optusnet.com.au
In any case, this shouldn't affect you, Christian, as it seems that your
version of the gcc compiler does not suffer the affliction.
PDL should now build fine for you, and pass all tests.

Most of the other stuff is over my head.

However this sounds to me like you thought i was looking for a workaround
to get it installed in my Perl. That is not the case and i was hoping to
see a patch for PDL itself come out of this so everyone can install it on
64bit activeperl and i can smoke it properly.

Additional info i discovered today for bulk88 in #win32, but might be
useful to you too:

AP 5.16.3 32 bit uses mingw 3.4.5 + SHAY/dmake-4.11-20080107-SHAY.zip
AP 5.16.3 64 bit uses mingw 4.5.4 + SHAY/dmake-4.12-20090907-SHAY.zip

[s***@optusnet.com.au]

-----Original Message-----
From: Christian Walde

Post by Christian Walde
However this sounds to me like you thought i was looking for a workaround
to get it installed in my Perl. That is not the case and i was hoping to
see a patch for PDL itself come out of this so everyone can install it on
64bit activeperl and i can smoke it properly.

But your problems are not indicative of any failing with PDL (or Inline) -
it's your setup that 's at fault and in need of repair.

The problem is identified and solved here:
http://sourceforge.net/apps/trac/mingw-w64/wiki/Answer%2064%20bit%20MSVC-generated%20x64%20.lib.

That link contains:

################################
Q:
Why crashes my 64 bit program when using a MSVC-generate x64 *.lib file?

A:
Linking using an MSVC-generated x64 *.lib file is _not_ supported. Yes the
x86 variant is supported but x64 is not, and yes binutils will be silent and
link but will output an all wrong binary.
[snip]
If you generate a binutils-compatbile *.a file by using gendef on the dll
and then compiling it, like:
gendef wpcap.dll
dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib
libwpcap.a --input-def wpcap.def ... then things will work.
################################

You're currently linking to "an MSVC-generated x64 *.lib file" (namely,
ActivePerl's lib/CORE/perl516.lib) ... and, as it says in the above faq
entry "this is _not_ supported". (It *is* supported for 32-bit compilers,
but not for 64-bit compilers.)

You need to 'cd' to your perl/bin directory and run:

gendef perl516.dll
(which will create perl516.def)

Then run:

dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib
libperl516.a --input-def perl516.def
(which will create libperl516.a ... which is suitable for your linker.)

Then move the generated 'libperl516.a' from your perl/bin folder to your
perl/lib/CORE/ folder (same location as perl516.lib).

Then, in ActivePerl/Config.pm, you need to override "libperl" to
"libperl516.a".

This is the same as how we overrode "ivtype" to "long long".
Firstly add "libperl" to that %COMPILER_ENV list near the beginning of the
file.
Then add the override libperl immediately below the ivtype override ... so
that we now have:

..........
_override("d_casti32", "define");
_override("ivtype", "long long");
_override("libperl", "libperl516.a");

Check that 'perl -V:libperl' reports 'libperl516.a'.
Then you should be right to go ... and all tests should pass for PDL (and
Inline) .

Sorry - I should have taken the time to elaborate this in my previous post.

Cheers,
Rob

[Christian Walde]

Post by s***@optusnet.com.au
But your problems are not indicative of any failing with PDL (or Inline)
- it's your setup that 's at fault and in need of repair.

Before i try to explain why it matters, i have to ask:

Does this mean PDL or Inline *cannot* work around this, or would *prefer*
not to?

[Chris Marshall]

I don't have ASPerl at the moment but before, when I needed
a compiler, you could use the ppm stuff to get a mingw. Presumably,
the same thing could (should?) work for 64bit ASPerls and would
have the responsibility of ensuring a correct perl build environment.

In general, I assume that the perl -V (i.e., use Config) information
is correct and complete. That seems *not* to be the case for your
smoke test environment. If we want it to work "out of the box" then
that problem needs to be fixed at the source rather than
piecemeal for every package that hit the 64bit wall.

I'm still waiting to see if the ASPerl build farm swallows the
PDL-2.007 release. The windows builds have not happened yet....

--Chris


On Mon, Oct 14, 2013 at 8:52 AM, Christian Walde

Post by Christian Walde

Post by s***@optusnet.com.au
But your problems are not indicative of any failing with PDL (or Inline) -
it's your setup that 's at fault and in need of repair.

Does this mean PDL or Inline *cannot* work around this, or would *prefer*
not to?
--
With regards,
Christian Walde
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Christian Walde]

On Mon, 14 Oct 2013 15:31:09 +0200, Chris Marshall

Post by Chris Marshall
I don't have ASPerl at the moment but before, when I needed
a compiler, you could use the ppm stuff to get a mingw. Presumably,
the same thing could (should?) work for 64bit ASPerls and would
have the responsibility of ensuring a correct perl build environment.
In general, I assume that the perl -V (i.e., use Config) information
is correct and complete. That seems *not* to be the case for your
smoke test environment. If we want it to work "out of the box" then
that problem needs to be fixed at the source rather than
piecemeal for every package that hit the 64bit wall.
I'm still waiting to see if the ASPerl build farm swallows the
PDL-2.007 release. The windows builds have not happened yet....

Thanks for the answer, that gives me a good view on your views. I'll
detail more later, when i have the time, but the crux here is:

My setup is the basic default setup for 64bit 5.16.3 ActivePerl. All the
software (Perl, compiler, dmake) in it is exactly as AP delivers it.

[Chris Marshall]

On Mon, Oct 14, 2013 at 9:57 AM, Christian Walde

Post by Chris Marshall
I don't have ASPerl at the moment but before, when I needed
a compiler, you could use the ppm stuff to get a mingw. Presumably,
the same thing could (should?) work for 64bit ASPerls and would
have the responsibility of ensuring a correct perl build environment.
In general, I assume that the perl -V (i.e., use Config) information
is correct and complete. That seems *not* to be the case for your
smoke test environment. If we want it to work "out of the box" then
that problem needs to be fixed at the source rather than
piecemeal for every package that hit the 64bit wall.
I'm still waiting to see if the ASPerl build farm swallows the
PDL-2.007 release. The windows builds have not happened yet....

Thanks for the answer, that gives me a good view on your views. I'll detail
My setup is the basic default setup for 64bit 5.16.3 ActivePerl. All the
software (Perl, compiler, dmake) in it is exactly as AP delivers it.

Yes, see David's email about one idea to fix this. I guess you don't
like the idea of ActiveState fixing the mingw ppm stuff on their end.
I guess that gives me a good view on your views.

--Chris

[David Mertens]

To be clear, I think this is a bug in ASPerl, but if we can solve this
problem for ASPerl users without requiring them to upgrade their Perls, I
think we have a win. But that assumes that somebody codes up Rob's
solution. :-)

Post by Chris Marshall
On Mon, Oct 14, 2013 at 9:57 AM, Christian Walde

On Mon, 14 Oct 2013 15:31:09 +0200, Chris Marshall <

Post by Chris Marshall
I don't have ASPerl at the moment but before, when I needed
a compiler, you could use the ppm stuff to get a mingw. Presumably,
the same thing could (should?) work for 64bit ASPerls and would
have the responsibility of ensuring a correct perl build environment.
In general, I assume that the perl -V (i.e., use Config) information
is correct and complete. That seems *not* to be the case for your
smoke test environment. If we want it to work "out of the box" then
that problem needs to be fixed at the source rather than
piecemeal for every package that hit the 64bit wall.
I'm still waiting to see if the ASPerl build farm swallows the
PDL-2.007 release. The windows builds have not happened yet....

Thanks for the answer, that gives me a good view on your views. I'll

detail

My setup is the basic default setup for 64bit 5.16.3 ActivePerl. All the
software (Perl, compiler, dmake) in it is exactly as AP delivers it.

Yes, see David's email about one idea to fix this. I guess you don't
like the idea of ActiveState fixing the mingw ppm stuff on their end.
I guess that gives me a good view on your views.
--Chris
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Christian Walde]

On Mon, 14 Oct 2013 16:07:08 +0200, Chris Marshall

Post by Chris Marshall
On Mon, Oct 14, 2013 at 9:57 AM, Christian Walde

Post by Christian Walde
On Mon, 14 Oct 2013 15:31:09 +0200, Chris Marshall

Post by Chris Marshall
I don't have ASPerl at the moment but before, when I needed
a compiler, you could use the ppm stuff to get a mingw. Presumably,
the same thing could (should?) work for 64bit ASPerls and would
have the responsibility of ensuring a correct perl build environment.
In general, I assume that the perl -V (i.e., use Config) information
is correct and complete. That seems *not* to be the case for your
smoke test environment. If we want it to work "out of the box" then
that problem needs to be fixed at the source rather than
piecemeal for every package that hit the 64bit wall.
I'm still waiting to see if the ASPerl build farm swallows the
PDL-2.007 release. The windows builds have not happened yet....

Thanks for the answer, that gives me a good view on your views. I'll detail
My setup is the basic default setup for 64bit 5.16.3 ActivePerl. All the
software (Perl, compiler, dmake) in it is exactly as AP delivers it.

Yes, see David's email about one idea to fix this. I guess you don't
like the idea of ActiveState fixing the mingw ppm stuff on their end.
I guess that gives me a good view on your views.

I do want them to fix it and I will bug them about it too. The short of it
is though: ActivePerl is not a focus of theirs, so things take a long time
to get out. Further there is a big install base which might not have the
choice to upgrade, or will at least have considerable inertia against
upgrading.

Thus, while i like a fix on the side of AP, i simply don't think it will
do any good in any reasonably useful time frame.

PS: This is text, so i can't tell if your last comment is carrying
sarcasm. If it does, please be aware that my comment you mirrored was made
in good faith with no ulterior intentions.

[Chris Marshall]

On Mon, Oct 14, 2013 at 10:14 AM, Christian Walde

Post by Christian Walde

Post by Chris Marshall
On Mon, Oct 14, 2013 at 9:57 AM, Christian Walde

Post by Christian Walde
On Mon, 14 Oct 2013 15:31:09 +0200, Chris Marshall

Post by Chris Marshall
I don't have ASPerl at the moment but before, when I needed
a compiler, you could use the ppm stuff to get a mingw. Presumably,
the same thing could (should?) work for 64bit ASPerls and would
have the responsibility of ensuring a correct perl build environment.
In general, I assume that the perl -V (i.e., use Config) information
is correct and complete. That seems *not* to be the case for your
smoke test environment. If we want it to work "out of the box" then
that problem needs to be fixed at the source rather than
piecemeal for every package that hit the 64bit wall.
I'm still waiting to see if the ASPerl build farm swallows the
PDL-2.007 release. The windows builds have not happened yet....

Thanks for the answer, that gives me a good view on your views. I'll
My setup is the basic default setup for 64bit 5.16.3 ActivePerl. All the
software (Perl, compiler, dmake) in it is exactly as AP delivers it.

So for the 64bit ASPerl you no longer have to request
mingw via ppm to get the compiler stuff? If so then this
is definitely a bug in the ASPerl distribution.

Post by Christian Walde

Post by Chris Marshall
Yes, see David's email about one idea to fix this. I guess you don't
like the idea of ActiveState fixing the mingw ppm stuff on their end.
I guess that gives me a good view on your views.

I do want them to fix it and I will bug them about it too. The short of it
is though: ActivePerl is not a focus of theirs, so things take a long time
to get out. Further there is a big install base which might not have the
choice to upgrade, or will at least have considerable inertia against
upgrading.
Thus, while i like a fix on the side of AP, i simply don't think it will do
any good in any reasonably useful time frame.

It seems a community-based fix could be more timely.

Post by Christian Walde
PS: This is text, so i can't tell if your last comment is carrying sarcasm.
If it does, please be aware that my comment you mirrored was made in good
faith with no ulterior intentions.

Thank you. Please feel free to contact me off list if you wish
to discuss "views", yours or mine. It is doubtful that any type
of mailing list exchange can provide a basis to really understand
others views.

--Chris

[s***@optusnet.com.au]

-----Original Message-----
From: Christian Walde

Post by Christian Walde
I do want them to fix it and I will bug them about it too.

I'm pretty sure I filed a ticket about this with their bugzilla tracker
years ago - shortly after perl-5.10.0 was released.

Post by Christian Walde
The short of it is though: ActivePerl is not a focus of theirs, so things
take a long time to get out.

And, beginning with perl-5.18, ActivePerl is being built using gcc-4.6.3 -
so this whole problem is then solved.
Their 64-bit ivtype is now already "long long" and the perl import library
is now "libperl518.a" - no need to override *any* config settings.
Of course, this also probably means that they'll *never* fix this bug that
exists for x64 builds of 5.16.3 and earlier that want to use a mingw
compiler.

Post by Christian Walde
Further there is a big install base which might not have the choice to
upgrade, or will at least have considerable inertia against upgrading.
Thus, while i like a fix on the side of AP, i simply don't think it will
do any good in any reasonably useful time frame.

Probably so - and it thus becomes a fix that needs to be done by the person
wanting to build/test perl extensions on x64 ActivePerl with a mingw
compiler.
It's not as if PDL developers can come up with some code that's magically
going to allow PDL to work reliably when an x64 compiler wants to link to an
MSVC-built lib.
As David said, the only solution would be to have the PDL build process
perform the fixes I have outlined. As well as being difficult to implement,
that is also the *wrong* thing for us to be doing IMO - and I personally
won't have anything to do with such an approach.

If you want to avoid doing the gendef/dlltool hack, another alternative is
to simply override "libperl" to "../../bin/perl516.dll".
This makes use of mingw's capability of being able to link to a dll. Many
people frown on this approach (I forget why), and say it's not the right
thing to do - but it worked flawlessly for me years ago when I used it
extensively with x64 ActivePerl 5.10.0 (build 1005) - and it works for me
still with Inline-0.53 and ActivePerl build 1600.

Cheers,
Rob

[David Mertens]

I don't know if this is necessarily a problem with Christian's setup as it
is with ASPerl. Given that you (Sisyphus) just gave a recipe for fixing it,
do you think it would be possible for someone to create a CPAN Distribution
whose sole purpose is to perform all of these manipulations when installed
on an ASPerl system? This way, modules such as Inline and PDL could simply
list that module in their dependency list and Just Work.


David

-----Original Message----- From: Christian Walde
However this sounds to me like you thought i was looking for a workaround

Post by Christian Walde
to get it installed in my Perl. That is not the case and i was hoping to
see a patch for PDL itself come out of this so everyone can install it on
64bit activeperl and i can smoke it properly.

But your problems are not indicative of any failing with PDL (or Inline) -
it's your setup that 's at fault and in need of repair.
http://sourceforge.net/apps/**trac/mingw-w64/wiki/Answer%**
2064%20bit%20MSVC-generated%**20x64%20.lib<http://sourceforge.net/apps/trac/mingw-w64/wiki/Answer%2064%20bit%20MSVC-generated%20x64%20.lib>
.
##############################**##
Why crashes my 64 bit program when using a MSVC-generate x64 *.lib file?
Linking using an MSVC-generated x64 *.lib file is _not_ supported. Yes the
x86 variant is supported but x64 is not, and yes binutils will be silent
and link but will output an all wrong binary.
[snip]
If you generate a binutils-compatbile *.a file by using gendef on the dll
gendef wpcap.dll
dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libwpcap.a
--input-def wpcap.def ... then things will work.
##############################**##
You're currently linking to "an MSVC-generated x64 *.lib file" (namely,
ActivePerl's lib/CORE/perl516.lib) ... and, as it says in the above faq
entry "this is _not_ supported". (It *is* supported for 32-bit compilers,
but not for 64-bit compilers.)
gendef perl516.dll
(which will create perl516.def)
dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libperl516.a
--input-def perl516.def
(which will create libperl516.a ... which is suitable for your linker.)
Then move the generated 'libperl516.a' from your perl/bin folder to your
perl/lib/CORE/ folder (same location as perl516.lib).
Then, in ActivePerl/Config.pm, you need to override "libperl" to
"libperl516.a".
This is the same as how we overrode "ivtype" to "long long".
Firstly add "libperl" to that %COMPILER_ENV list near the beginning of the
file.
Then add the override libperl immediately below the ivtype override ... so
..........
_override("d_casti32", "define");
_override("ivtype", "long long");
_override("libperl", "libperl516.a");
Check that 'perl -V:libperl' reports 'libperl516.a'.
Then you should be right to go ... and all tests should pass for PDL (and
Inline) .
Sorry - I should have taken the time to elaborate this in my previous post.
Cheers,
Rob
______________________________**_________________
PDL-porters mailing list
http://mailman.jach.hawaii.**edu/mailman/listinfo/pdl-**porters<http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters>

[Christian Walde]

On Mon, 14 Oct 2013 15:52:33 +0200, David Mertens

Post by David Mertens
I don't know if this is necessarily a problem with Christian's setup as
it is with ASPerl. Given that you (Sisyphus) just >gave a recipe for
fixing it, do you think it would be possible for someone to create a
CPAN Distribution whose sole >purpose is to perform all of these
manipulations when installed on an ASPerl system? This way, modules such
as >Inline and PDL could simply list that module in their dependency
list and Just Work.

That seems to be the best solution and is exactly what i was pondering
already. :)