Erland Sommarskog
2016-07-13 16:18:24 UTC
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].
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, ***@sommarskog.se
Erland Sommarskog, Stockholm, ***@sommarskog.se