Re: loadable library and perl binaries are mismatched
[email protected] Thu, 14 Jul 2016 10:54:04 +1000
| Newsgroups | perl.xs |
|---|---|
| Message-ID | <2B7313121DE84CA39714C0D15C2EEA48@OwnerPC311012> |
-----Original Message----- From: Erland Sommarskog Sent: Thursday, July 14, 2016 2:18 AM To: [email protected] Subject: loadable library and perl binaries are mismatched > 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? That won't matter so long as nvtype/nvsize for the perl that builds your binary distribution matches the nvtype/nvsize of the perl on which that distro is being run. (Otherwise you have "binary incompatibility" - which will produce a different error.) I struck a similar problem a while back: http://www.nntp.perl.org/group/perl.perl5.porters/2015/06/msg228601.html Turned out my problem there was that the Makefile.PL was setting CCFLAGS incorrectly (though it was only perl-5.22.0 and later that were affected). As kmx had discovered in https://github.com/tsee/extutils-cppguess/issues/9, it was the missing -DPERL_IMPLICIT_SYS that was the problem. Looking at http://cpansearch.perl.org/src/SOMMAR/Win32-SqlServer-2.009/makefile.pl, I can see that you do mess with CCFLAGS, but it looks like -DPERL_IMPLICIT_SYS will still be there. Maybe there's another missing (crucial) flag introduced by your change to CCFLAGS. Or maybe you've hit an entirely different issue. XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK is something I haven't previously encountered. Is there some documentation that suggests that defining it to 1 is a valid thing to do ? Cheers, Rob