On Wed, 05 Nov 2008, Serguei Trouchelle wrote:
> listmail wrote:
>>> Dialog title: perl.exe - Entry Point Not Found Dialog text : The
>>> procedure entry point Perl_sv_2uv_flags could not be located in the
>>> dynamic link library perl58.dll. Maybe I need to jump to build 824?
>>> I have to be careful here because I don't necessarily want to blow
>>> up my Net::SSH::W32Perl setup as I don't know the status of the
>>> soulcage repo that I used to quite some time ago to get that
>>> installed.
> I googled a thread from this mailing list about this issue:
> http://www.mail-archive.com/perl-win32-users@listserv.activestate.com/msg36994.html
> It looks like builds prior to 822 are not fully binary-compatible with
> recent versions.

Binary compatibility is a one-way street: Module compiled with an
earlier version of ActivePerl should always be compatible with later
releases of ActivePerl (as long as you stay within the same major
version; 5.8 modules are not compatible with

The reverse however is not true: In general you can not assume that a
module compiled with a later version of ActivePerl will work with and
older installation.

This is the reason why the "old" ActiveState PPM repository was always
building with ActivePerl 806 for 5.8: The modules can be loaded into any
later ActivePerl release. If you build with 824, then you can only load
them into 824. You may be lucky and be able to load them into 822, but
that isn't guaranteed either.

Note that this limitation is not specific to ActivePerl; it applies to
all Perl releases.  There are 2 types of changes that can be made to
Perl maintenance releases: Additional data fields are added to the end
of internal data structures and/or additional external API are being

A module compiled with an older version of Perl will not access these
additional data members and not call the new APIs, therefore it can
be used by a later Perl version.  A module compiled with the later
Perl however will use the header files from this Perl version and
may both access the additional structure members or call the new APIs.
This typically happens because the Perl header files will change
some of the macros that are being used to access the Perl internals.

If you call a new API function, then the module will simply not load
when you run it with an older Perl because that version doesn't export
the new symbol.  But when you only access the new data members, then
you won't get any warnings but may still run into data corruption
because you are now accessing memory that has not been allocated by
the older Perl interpreter.


PS: The "new" PPM repositories from ActiveState are being built using
ActivePerl 818 for 5.8 and will therefore be compatible with all
ActivePerl 5.8.8 builds.  These repositories are currently only
enabled for the new 824 builds, but we'll add server redirects for
818..823 probably later today.  By moving the baseline to 5.8.8
we can now build a lot of modules that before couldn't be built
because they required 5.8.1 or later and therefore failed under

Perl-Win32-Users mailing list
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Reply via email to