Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
loadable library and perl binaries are mismatched
50 views
Skip to first unread message
Erland Sommarskog
Jul 13, 2016, 12:30:04 PM7/13/16
to per...@perl.org
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
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
Elizabeth Mattijsen
Jul 13, 2016, 4:00:04 PM7/13/16
to per...@perl.org
Erland,
> On 13 Jul 2016, at 21:52, Erland Sommarskog <esq...@sommarskog.se> wrote:
>
> OK, so I found out that this handshake test is new to 5.22. That explains
> why it does not fail on 5.20. :-)
>
> Furthermore, I find that if I add this line to my .XS file:
>
> #define XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK 1
>
> I circumvent the check, and after this I'm able to run my DLL with
> ActivePerl.
>
> I still appreciate any hints to build my Perl so that I don't have to
> do this.
This list is pretty dead, in my experience. Maybe you will have a better chance of getting an answer on p5p (perl5-...@perl.org) .
Liz
> On 13 Jul 2016, at 21:52, Erland Sommarskog <esq...@sommarskog.se> wrote:
>
> OK, so I found out that this handshake test is new to 5.22. That explains
> why it does not fail on 5.20. :-)
>
> Furthermore, I find that if I add this line to my .XS file:
>
> #define XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK 1
>
> I circumvent the check, and after this I'm able to run my DLL with
> ActivePerl.
>
> I still appreciate any hints to build my Perl so that I don't have to
> do this.
This list is pretty dead, in my experience. Maybe you will have a better chance of getting an answer on p5p (perl5-...@perl.org) .
Liz
Erland Sommarskog
Jul 13, 2016, 4:00:04 PM7/13/16
to per...@perl.org
OK, so I found out that this handshake test is new to 5.22. That explains
why it does not fail on 5.20. :-)
Furthermore, I find that if I add this line to my .XS file:
#define XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK 1
I circumvent the check, and after this I'm able to run my DLL with
ActivePerl.
I still appreciate any hints to build my Perl so that I don't have to
do this.
why it does not fail on 5.20. :-)
Furthermore, I find that if I add this line to my .XS file:
#define XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK 1
I circumvent the check, and after this I'm able to run my DLL with
ActivePerl.
I still appreciate any hints to build my Perl so that I don't have to
do this.
sisy...@optusnet.com.au
Jul 13, 2016, 9:00:02 PM7/13/16
to per...@perl.org, Erland Sommarskog
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
Erland Sommarskog
Jul 14, 2016, 3:30:05 AM7/14/16
to per...@perl.org
(sisy...@optusnet.com.au) writes:
> 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.
I think I saw that thread when googling the problem.
> 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.
run-time library statically, so that I don't have distribute them
with the binary. And there is some change for the optimizer flags,
because else one of my test cases fails for reasons I don't understand.
> 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 ?
guess it could break in any release, including 5.24 which I have not
tested yet.
Erland Sommarskog
Jul 15, 2016, 8:00:03 AM7/15/16
to per...@perl.org
Erland Sommarskog (esq...@sommarskog.se) writes:
symbols when linking and I gave it up.
In any case, notice that the problem is not to get the module to run
with the Perl I build it under. The problem is to get the binary to
run with other Perls built for the same platform.
>> 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 ?
>
> I don't think so. I figured out by reading the source code in XSUB.h. I
> guess it could break in any release, including 5.24 which I have not
> tested yet.
I have now tested with 5.24 and the same trick works there too.
In case someone else find this thread in the future, I should point out
there are several BOOTCHECK macros that all lead to Perl_xs_handshake
which implements this handshake check. I found that the macro above is
the one that applied to my code by looking at the generated CPP code.
So if you run into this, and can't find no other way to work around it,
you will need to look what XS produces and in XSUB.h to figure out
what to do. But first check that you don't have any major flag mismatch
like PERL_IMPLICIT_SYS like sisyphus had. And don't be surprised if
you kill the check like I did, that things to crash boom bang later.
It has worked for me ...so far.
> (sisy...@optusnet.com.au) writes:
>> 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.
>
> Could be. I might give it try. I meddle with the flags to link the
> run-time library statically, so that I don't have distribute them
> with the binary. And there is some change for the optimizer flags,
> because else one of my test cases fails for reasons I don't understand.
I tried to disable my alterations, but this lead to a number of unresolved
>> 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.
>
> Could be. I might give it try. I meddle with the flags to link the
> run-time library statically, so that I don't have distribute them
> with the binary. And there is some change for the optimizer flags,
> because else one of my test cases fails for reasons I don't understand.
symbols when linking and I gave it up.
In any case, notice that the problem is not to get the module to run
with the Perl I build it under. The problem is to get the binary to
run with other Perls built for the same platform.
>> 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 ?
>
> I don't think so. I figured out by reading the source code in XSUB.h. I
> guess it could break in any release, including 5.24 which I have not
> tested yet.
In case someone else find this thread in the future, I should point out
there are several BOOTCHECK macros that all lead to Perl_xs_handshake
which implements this handshake check. I found that the macro above is
the one that applied to my code by looking at the generated CPP code.
So if you run into this, and can't find no other way to work around it,
you will need to look what XS produces and in XSUB.h to figure out
what to do. But first check that you don't have any major flag mismatch
like PERL_IMPLICIT_SYS like sisyphus had. And don't be surprised if
you kill the check like I did, that things to crash boom bang later.
It has worked for me ...so far.
bulk 88
Jul 15, 2016, 8:45:02 AM7/15/16
to Erland Sommarskog, per...@perl.org
----------------------------------------
> To: per...@perl.org
> Subject: loadable library and perl binaries are mismatched
> From: esq...@sommarskog.se
> Date: Wed, 13 Jul 2016 18:18:24 +0200
>
> 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.)
>
Your XS DLL and perl core do not agree on -D options, or the config.h files used to compile both are different. Perl XS DLLs/SOs are not binary compatible with anything but the perl binary that built them. The high 16 bits of the handshake key are the size of the interp struct. Your XS module and perl core do NOT agree on where the memory offsets for various members in the interp struct are.
0 new messages