I have an XS module to permit Perl scripts access SQL Server through OLE DB. Besides a source-code only distribution, I also maintain a binary distribution for ActivePerl and for 5.18 and 5.20 I have also supported Strawberry Perl.
Up to Perl 5.16 it was easy - since ActivePerl was labeled to have been built with Visual Studio (MSVC), I could build my module with Visual Studio as well. With Perl 5.18, ActiveState switched to gcc. What I did was to build Perl from sources with MSVC and build my module in that Perl environment. The binary produced runs well with ActivePerl and Strawberry Perl. I am not trying to redo that stunt with Perl 5.22 and 5.24 and it works for 64-bit Perl. However, for 32-bit Perl, I get this error message when I try to invoke the module on ActivePerl or Strawberry Perl 5.22: SqlServer.c: loadable library and perl binaries are mismatched (got handshake key 0B080080, needed 0AF00080) (The error message for 5.24 is the same, but with different handshake keys.) I've tried to identify the configuration differences, and I note that perl -V reports longblkind=0 for the Perl that I've built with MSVC, while for ActivePerl the setting is 3. There are a few more differences, but these difference apply to 5.20 as well. I also note that there is a new feature in Perl 5.22 with USE_LONG_DOUBLE which is said not to be supported with MSVC. Am I right to suspect that this setting is the culprit? Before anyone suggests that I should build my module with gcc, this is not really an option for the moment. My expertise is with SQL Server, not with C++, and using gcc is way outside my comfort zone, and I am not even sure that gcc groks the include file needed - it may be peppered with MS-only syntax. A more likely option is simply not to provide binary modules for 32-bit Perl for 5.2[24]. -- Erland Sommarskog, Stockholm, esq...@sommarskog.se
