----- Original Message ----- From: "Jan Dubois" <[EMAIL PROTECTED]> To: "'Sisyphus'" <[EMAIL PROTECTED]>; "'perl-win32-users'" <perl-win32-users@listserv.ActiveState.com> Sent: Monday, March 03, 2008 5:06 AM Subject: RE: Not all functions are exported by the perl dll
> On Sun, 02 Mar 2008, Sisyphus wrote: >> Hi, >> Some time back I asked about the inability of XS to access >> Perl_report_uninit() on Win32 ... though the function is accessible from >> XSubs on linux. Jan Dubois explained thus: >> >> --- quote --- >> "..Perl_report_uninit() is not a public Perl API, so extensions are not >> allowed to call it. On Linux this cannot be enforced as all internal >> symbols >> are being exported anyways, but on Windows (and AIX) you can only call >> APIs >> that are marked as "public" in the embed.fnc file in the core Perl >> distribution. >> >> In general it is a good idea to check `perldoc perlapi`. If the function >> isn't listed in there, then you are not allowed to use them in an >> extension...." >> --- end quote --- >> >> I've now started to wonder "why is it so?". That is, why *not* allow the >> calling of *all* functions on Win32 (as can be done in linux) ? >> >> I don't doubt that there are good reasons for imposing these limitations >> ... >> I'm merely wondering what those "good reasons" are :-) > > The reason is that those functions are not considered to be part of the > public Perl API. For all public APIs there is an effort to keep at least > source-level compatibility between Perl versions, even when they are no > longer binary compatible. > [snip] Thanks for the explanation. It seems that the goal posts were moved with the release of perl 5.10 - a number of functions that were private in perl 5.8 are now apparently public. For example, Data-Alias-1.07 fails to build on perl 5.8 (Windows and AIX only) because it tries to access the private perl API. The make process terminates as follows: Alias.o:Alias.c:(.text+0x2fe): undefined reference to `Perl_av_reify' Alias.o:Alias.c:(.text+0x49d): undefined reference to `Perl_vivify_defelem' Alias.o:Alias.c:(.text+0x6e6): undefined reference to `Perl_av_reify' Alias.o:Alias.c:(.text+0x702): undefined reference to `Perl_vivify_defelem' Alias.o:Alias.c:(.text+0x312e): undefined reference to `Perl_av_reify' Alias.o:Alias.c:(.text+0x364d): undefined reference to `Perl_setdefout' Alias.o:Alias.c:(.text+0x36fd): undefined reference to `Perl_lex_end' Alias.o:Alias.c:(.text+0x3df3): undefined reference to `Perl_qerror' Alias.o:Alias.c:(.text+0x44b1): undefined reference to `Perl_mod' Alias.o:Alias.c:(.text+0x46e5): undefined reference to `Perl_mod' Alias.o:Alias.c:(.text+0x4724): undefined reference to `Perl_mod' Alias.o:Alias.c:(.text+0x4bb9): undefined reference to `Perl_yylex' Alias.o:Alias.c:(.text+0x4e72): undefined reference to `Perl_op_clear' Alias.o:Alias.c:(.text+0x37b9): undefined reference to `Perl_pop_return' collect2: ld returned 1 exit status dmake: Error code 129, while making 'blib\arch\auto\Data\Alias\Alias.dll' (Actually the makefile.pl detects that the build aint gunna work and dies - but if you remove that detection capability from the makefile.pl, then the build process as terminates above.) But on Win32 perl 5.10, the exact same source builds and tests fine. Were all of those 5.8 private functions (specified above) made public on perl 5.10 just to accommodate Data::Alias ? Or are there other forces at work here ? Cheers, Rob _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
