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://email@example.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 5.10). 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 defined. 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. Cheers, -Jan 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 18.104.22.1686. _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs