If you have some ideas as to how this difficulty might best be overcome, please share them,

There would appear to be 3 possible ways forward:

1. Persuade the p5p guys to export these entrypoints on win32/AIX etc.

   As their privacy cannot be enforced on the defacto base development platform, and module authors are finding these functions useful(*), only protecting them on platforms that have that ability almost guarantees that those platforms will be seen as the "awkward squad" for failing to build modules that "work just fine on unix".

   (*)I found several other modules on my system that contain references to av_reify: DBI (does build); Devel::FastProf (doesn't); Inline (does); Storable (does); threads (does); Time::HiRes (does); (My own) Win32::Fmode! (which does).

   In the latter case, the only reference is in ppport.h, which is automatically generated/incorporated by the "build & packaging process" and I do not pretend to understand. The same may be true of all the other packages that do build. Though DBI seems to be different?

2. Build a dll that contains (copies) of all the non-api functions visible to linux authors for use in building modules that *need* them.

   A recipe for disaster if ever I heard one, but no more so than the other option randyk mentioned. Ie. C&Ping the source code into the individual modules. At least if a single 'compatibility' module/DLL was available, there would only be one place to try and keep in sync with the P5 sources.

3. Accept the status quo.

   Accept that there will be a bunch of modules that will build on linux--because although the authors are playing fast and loose with the 'rules' of what internal APis they use, there is no way to enforce those rules--that will not build on other platforms where those rules can be enforced.

   Kinda reminds me of the state of play with the UK and EU. The UK rigidly enforces EU rules, even those that it voted against, on it's own citizens, even though other EU states (often those that voted for or even vetoed the legislation into existence), quietly allow their citizens to flout or just outright ignore those rules.

   It's also remeniscent of another debate between sauoq and others elsewhere on PM. Basically, it's better to be very careful about what laws you put on the books in the first place, than to try and deal with the gamut of loopholes, workarounds and bypasses that will ensue when bad legislation gets through for the lack of challenge.

Seems that there is scope for a reassessment of the decision making process that choses which APIs are public and which not. That would inevitably need to include discussion of why those authors that are using private APIs in their extensions are doing so, and is there any alternative. It might also prompt a discussion of moving to a 'permissive by default' stance that would expose all internal APIs except where there was specific reason for not doing so.

However, I can well understand that the p5p guys would view any such discussion with skepticism, if not outright hostility. It's a fairly common rule to restrict the exposure of an API to the minimum commensurate with functionality, and I foresee considerable resistance to attempting to change that. Were I on the other side of the debate, I might find myself in that camp also.

The bottom line is that for the vast majority of Win32 Perl users that choose to use binary builds, there will always be some subset of modules (usually the more useful ones!), that they will continue to be prevented from using by circumstances beyond their control. If the authors of these extensions are finding that they need to ignore the public/private boundaries of the Perl API in order to get what they are doing done, it tends to indicate there is something wrong with the positioning of the boundaries--but that's a discussion I am unqualified to lead.

Other possibilities--like every individual using Cygwin; or AS patching embed.fnc--are simply spreading the 'EU states ethic' that you simply ignore the rules that you dislike.