Re: CPAN test problem

If you have a look at the FAIL report you will see:

cygwin-thread-multi-64int
[download]

which might explain a few things..

Update: if the scalar is 4 bytes long

Also in the FAIL report is: ivsize=8

Update2: I tried to install your module on 64-bit Windows. First it failed because you are using Build, and that failed calling Probe::Perl, which is not in the dependency list. Using cpanp hung, so I tried cpan and install, that failed because Build tried to call 'make', and it should be 'nmake'. So I tried again manually now that Build had been installed. The README file said to type "Build make" but that said "No action 'make' defined". So I tried "Build test" and that failed trying to load bufferoverflowU.lib - which is a well-known issue on Windows. Normally I would edit the Makefile, but Build is not creating one. At that point I gave up.

Comment on Re: CPAN test problem Select or Download Code

Replies are listed 'Best First'.
Re^2: CPAN test problem by cmac (Monk) on Apr 12, 2010 at 16:59 UTC
Thank you for trying to install IP::World. This is the first module for which I've used Module::Build, and other problems have prevented testing from getting very far on Windows. Probe::Perl is definitely in the 'configure_requires' dependency list in Build.PL of version 0.33. I have changed from Module::Build=>0.36 in 'build_requires' to Module::Build=>0.3607 in 'configure_requires' which may help get the whole thing off to a better start. './Build make' in README was dumb of me. I've changed it to './Build' for 0.34. Sorry. The bufferoverflowU.lib business seems to be well-known as you say, but I wasn't able to find a solution that a module author can use. Do you know of anything I can do to work around this? Build will only produce a Makefile if instructed to do so. Do I need to do this to help users deal with the bufferoverflowU.lib problem? May I send you a 0.34 package to try before I upload it to CPAN? This would be in the next day or two. Thanks, cmac	[reply]
Re^3: CPAN test problem by syphilis (Archbishop) on Apr 13, 2010 at 07:28 UTC
The bufferoverflowU.lib business seems to be well-known as you say, but I wasn't able to find a solution that a module author can use There's not much a module author can do about this - nor is it the responsibility of a module author to deal with this. IIUC, this is something that cdarke should attend to - by removing "bufferoverflowU.lib" from the "libs" and "perllibs" entries in lib/Config_heavy.pl. The problem is, I believe, simply that perl's configuration info is misconfigured (duh :-) for the particular compiler that cdarke has chosen to use, and the only person in a position to correct this is cdarke. Another solution would be for cdarke to switch to using the compiler that built perl in the first place. Then no amendments to Config_heavy.pl would be needed. Cheers, Rob	[reply]