Thirded. I use AS builds, MSC v6 and nmake v7. I install most modules manually. Downloading the .gz; use gunzip and tar from UnxUtils; then the four part mantra.

Some modules that have particularly complex dependancies on third party modules, GD for example, I have built myself, but it is simply easier to use a PPM if it is available.

The main problem I encounter when building XS modules is unresolvable externals, usually from Perl%x.dll. The source of this problem is that win32 allows the programmer to specify which entrypoints in .dll are exported. This is used on win32 builds to ensure that only those entrypoints that are part of the official PerlApi are exported.

Under *nix using gcc et al. either a) has no way to limit what is exported from an .so; b) there is a mechanism but it isn't used. Either way, the result is that programmers writing XS modules under *nix, frequently use functions from perl58x.so that aren't officially a part of the PerlApi and don't notice because they get resolved and work. But when someone comes to try and build those modules on win32, those unofficial apis won't resolve. The originating authors without access to/interest in win32 simply put the problem down to "windoze" and that's where it ends.

If one #define was changed to allow all the functions in perl5x.dll to be exported, another huge swath of failures would disappear.

If one #define was changed to allow all the functions in perl5x.dll to be exported, another huge swath of failures would disappear

This, I expect, alludes to (eg) your attempts to build Data::Alias as discussed in From whence comes perl-5.8.6-smartmatch.tar?.

Is it really just a matter of changing one #define ? If so, which one ? - and what's the change ? It could be interesting to build perl with that one define changed appropriately - and then see what happens as a result of that change. (Did we ever determine the reason that not all functions are exported ?)

Cheers,
Rob

(Did we ever determine the reason that not all functions are exported ?)

I think you pretty much answered that question when you quoted Jan Dubois. Which you might summarise as "because they can" on some platforms.

Try editing perl.h line ~3943 (5.8.8 build)

#  define PERL_CALLCONV __declspec(dllexport)
[download]

Without the above edit, perl58.dll from the AS817/5.8.8 distribution:

C:\test>pushd \AS817\perl\bin

C:\AS817\perl\bin>dumpbin /exports perl58.dll | wc -l
   1457

C:\AS817\perl\bin>dumpbin /exports perl58.dll | find "av_reify"

C:\AS817\perl\bin>
[download]

With the above change, perl58.dll(5.8.8):

c:\Perl\src\perl-5.8.8>dumpbin /exports perl58.dll | wc -l
   1995

c:\Perl\src\perl-5.8.8>dumpbin /exports perl58.dll | find "av_reify"
        627  272 00001000 Perl_av_reify
[download]

How many problems those extra 500 exports will fix I'm not sure, but I'm betting quite a few.

Whether it will work with 5.10 I'll tell you in about 1/2 hour.

Update: Seems to work similarly for 5.10 also:

[10:50:31.10]C:\Perl\src\perl-5.10.0>dumpbin /exports perl510.dll | wc
+ -l
   1993

[10:50:47.42]C:\Perl\src\perl-5.10.0>cd \Perl510\bin

[10:50:59.53]C:\Perl510\bin>dumpbin /exports perl510.dll | wc -l
   1387
[download]

And the (summary) output from nmake test looks 'normal':

Failed Test          Stat Wstat Total Fail  List of Failed
----------------------------------------------------------------------
+---------
../ext/IO/t/io_dup.t                6    4  2-5
../lib/lib.t            5  1280    13    0  ??
comp/multiline.t                    6    2  5-6
io/dup.t                           29    6  2-7
 (1 subtest UNEXPECTEDLY SUCCEEDED), 56 tests and 1083 subtests skippe
+d.
Failed 4/1470 test scripts. 12/189314 subtests failed.
Files=1470, Tests=189314, 1264 wallclock secs ( 0.00 cusr +  0.00 csys
+ =  0.00 CPU)
Failed 4/1470 test programs. 12/189314 subtests failed.
NMAKE : fatal error U1077: '..\perl.exe' : return code '0xff'
Stop.
[download]

Whether it will break anything anywhere, or is backwards compatible with 5.0 again I do not know.

And where it leaves all the shenanigins played out by embed.pl & regen_lib.pl and all the work that goes into maintaining embed.fnc, pp.sym, intrpvar.h, perlvars.h and thrdvar.h is another open question.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Perl has lots of modules that have nothing to do with *NIX. To use those modules you need make. Let me give you an example. Consider the Template module.

The PPM for Template is listed as 1.11(from Activestate), the current version on CPAN is 2.19. I was using version 2.15 recently and came across a bug in which it does not like to using DateTime modules in the template itself( example: can be found here). The answer was to use the XS version of Template The XS version requires make(refer to Corion's post for clarity), nmake did not work. I tried to find a compiled version, and in the Template tarball the INSTALL file refers to a web site that is about 4 years out of date. I got lucky, the bug was fixed in the non-XS version of Template in 2.19, but these sorts of situations can be common.

More than a few times I have had to go back and forth between CPAN and PPM trying to get a combination of modules from either or to get the functionality that I want. It is not fun.

The XS version requires make (nmake did not work).

This is wrong on at least two levels.

There are three flavours of make-style programs for Windows Perl - nmake.exe from Microsoft, dmake.exe (originally Watcom?) and the Borland

make.exe</p>. ActiveState Perl is the only Perl that uses and supports
+ PPM, and it will always be configured to use  <c>nmake.exe</p>.
<p>If you want to <i>install</i> modules via CPAN, you need a <c>make
[download]

-style program. If you want to compile XS components, you need not only a make-style program but also the (exact) C compiler that your Perl was compiled with. ActiveState Perl is built using Microsoft Visual C++ 6.0 (MSVC6), so you will need that. You can get adventurous and also configure it to use the MinGW build of gcc, which then turns your ActiveState Perl into a Perl that can easily build self-contained XS distributions from CPAN as well.

I run ActiveState Perl + MinGW + a recent nmake.exe and I have installed on my laptop a local CPAN-mirror which is updated daily, so even when in the air or under water I can still install almost any module I like.