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