Aaah ... yes, I guess you could solve the problem by convincing the porters that they are being overzealous.

Another way of interpreting what I wrote is that the compiler/linker/build process is being overzealous on Win32.

Having read the mailing list thread, it strikes me that the whole #define PERL_CORE / #define PERL_EXT / marking of APIs as EX and not A, is exactly what I'm suggesting.

Export the functions without making them a part of the official API. The only argument is whether it is done piecemeal for those non-api entrypoints used by non-conformant but 'accepted as useful' modules. Or pragmatically, to match the situation that exists on the reference platform.

Note though that I am not trying to persuade anyone such a change should be made. Only pointing out that life for Win32 users and developers, as well as non-Win32 developers who's code breaks when ported to win32, would be much simpler were that change made.

For now, I'm simply trying to build all the modules that I've grown dependant upon with 5.8.x into my 5.10 build so that I can move over to using the later as my default. And I am finding it far simpler to manually build the modules using a single compiler command line, than to either get PPMs for 5.10 that work, or resolve the problems with the generated makefiles.

The other day I spent just 15 minutes to work out the command line required to build Win32::Daemon manually. I had already spent nearly 5 hours trying to work out how to adapt the generated makefile--and failed. And I've previously spent literally weeks trying to work out, or get advice here and elsewhere, on how to get EU::MM to produce the makefile that I've worked out is required to build a package.

It's just a case of following the path of least resistance. Both with the tools and the powers that be.