Re^5: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000)

in reply to Re^4: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000)
in thread XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000)

Sorry if that sounded harsh (re: cross-posting), it's just polite to let others know.

I think you can safely ignore those ENOENTs because it's Perl trying various locations until it hits the right one - see the eventual open ... O_RDONLY. Memo-to-self: oh poor harddisk. So, filter those out please. For example at the terminal type: whatever-strace-command-you-ran | grep -v ENOENT and feel free to filter out other irrelevant blabber. Remember you are looking for a successful library open and then a failure because of the handshake. That can be quite a few lines apart.

Here is a successful module and library open:

stat("/home/rg8239/perl5/perlbrew/perls/perl-5.32.0/lib/5.32.0/x86_64-
+linux/Time/HiRes.pm", {st_mode=S_IFREG|0444, st_size=25689, ...}) = 0
open("/home/rg8239/perl5/perlbrew/perls/perl-5.32.0/lib/5.32.0/x86_64-
+linux/Time/HiRes.pm", O_RDONLY) = 5
stat("/home/rg8239/perl5/perlbrew/perls/perl-5.32.0/lib/5.32.0/x86_64-
+linux/auto/Time/HiRes/HiRes.so", {st_mode=S_IFREG|0555, st_size=28181
+, ...}) = 0
[download]

From the output you posted my filter produced this:

stat("/bin/tar", {st_mode=S_IFREG|0755, st_size=178728, ...}) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
stat("/usr/bin/unzip", {st_mode=S_IFREG|0755, st_size=115232, ...}) = 
+0
--- SIGCHLD (Child exited) @ 0 (0) ---
stat(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
--> Working on List::MoreUtils
Fetching http://www.cpan.org/authors/id/R/RE/REHSACK/List-MoreUtils-0.
+428.tar.gz ... --- SIGCHLD (Child exited) @ 0 (0) ---
stat("List-MoreUtils-0.428.tar.gz", {st_mode=S_IFREG|0644, st_size=146
+030, ...}) = 0
OK
--- SIGCHLD (Child exited) @ 0 (0) ---
--- SIGCHLD (Child exited) @ 0 (0) ---
[download]

Are tar and unzip working? Why those SIGCHLD? I can't explain those, perhaps someone else can.

Please remember that it's you doing the debugging. So, filter out irrelevant ENONENTs and perhaps other noise, zoom in to the failed handshake and make sure that in your log the failed handshake library is shown (in an open() statement hopefully)

Comment on Re^5: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000) Select or Download Code

Replies are listed 'Best First'.
Re^6: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000) by rgren925 (Beadle) on Aug 03, 2020 at 20:29 UTC
No offense taken. I understand the thoughtlessness and rudeness of posting the same issue concurrently on multiple forums--wasting people's time and good will. I just didn't grasp the nuances. Point taken and understood I pored through the output after eliminating the ENOENT. There was nothing unusual at the point of the handshake. However, these lines jumped out as pulling system libraries in at compile time... `cc -c -I. -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFIL +E_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"0.428\" -DXS _VERSION=\"0.428\" -fPIC "-I/home/rg8239/perl5/perlbrew/perls/perl-5.3 +2.0/lib/5.32.0/x86_64-linux/CORE" XS.c rm -f blib/arch/auto/List/MoreUtils/XS/XS.so cc -shared -O2 -L/usr/local/lib XS.o -o blib/arch/auto/List/MoreUti +ls/XS/XS.so \ \ chmod 755 blib/arch/auto/List/MoreUtils/XS/XS.so` [download]	[reply] [d/l]
Re^7: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000) by bliako (Monsignor) on Aug 04, 2020 at 08:49 UTC
OK this looks like another problem. First as I suggested and ikegami too: blank the 2 env vars PERL5LIB and LD_LIBRARY_PATH. I think it is not enough to do that in the shell because perlbrew may make decisions based on these. So, make sure that in your shell init (e.g. ~/.bashrc and system-wide /etc/bashrc or something) the first is blank. The 2nd I also believe it should be blank but I am not aware of your local settings or other packages changing it. A good rule of thumb is that the 2nd should not have anything perl-related set during shell init. Later of course perlbrew may set these I am not sure but that's ok. From the output you cited above, it's weird that the include dirs are taken into account but not the library's (EDIT: not sure whether `-L/perbrew/perl/...` should be present or not during XS.c compilation.). So, still a mixup. Here is what happens in my linux system without perlbrew: cp lib/List/MoreUtils/XS.pm blib/lib/List/MoreUtils/XS.pm Running Mkbootstrap for XS () chmod 644 "XS.bs" "/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- XS.bs blib +/arch/auto/List/MoreUtils/XS/XS.bs 644 "/usr/bin/perl" "/usr/share/perl5/vendor_perl/ExtUtils/xsubpp" -typem +ap '/usr/share/perl5/ExtUtils/typemap' XS.xs > XS.xsc mv XS.xsc XS.c gcc -c -I. -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=form +at-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexcep +tions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/ +rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-anno +bin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clas +h-protection -fcf-protection -fwrapv -fno-strict-aliasing -I/usr/loca +l/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -DVERSION=\ +"0.428\" -DXS_VERSION=\"0.428\" -fPIC "-I/usr/lib64/perl5/CORE" XS. +c [download] Notice that there are quite a few perl-version related things like `"/usr/bin/perl", "/usr/share/perl5/vendor_perl/ExtUtils/xsubpp", '/usr/share/perl5/ExtUtils/typemap'`. Do all these paths agree with your perlbrew'ed Perl? P.S. I think you should also send a message to syphilis too about this last error. EDIT: Bottomline: now that you have perlbrew perhaps start fresh from the beginning to see a) how it is compiled using the new settings (for example to confirm if correct binaries and library paths are used), b) where it fails if it does, c) strace output filtering out noise to see the fullpath of the library failing the handshake. It is important to filter noise and irrelevant bits like the ENOENTs but give us the important bits like what binary creates the XS.xsc - also, it is more convenient for me to deal with this issue with as little delay as possible between replies. It is difficult to me to switch back and forth contexts.	[reply] [d/l] [select]
Re^8: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000) by syphilis (Archbishop) on Aug 04, 2020 at 14:03 UTC
P.S. I think you should also send a message to syphilis too about this last error. Which error is that ? I don't understand how it happens that the XS module Test::LeakTrace is fine for the OP, but the XS module List::MoreUtils::XS is not. I keep thinking that should be giving us a clue ... but I don't see any clues. I compared the way both modules built on the OP's perl-5.30.3 and both build in essentially the same way. In the (below) copy'n'paste, the first line of each pair of lines is from the Test::LeakTrace build, the second line is from the List::MoreUtils::XS build: Running Mkbootstrap for LeakTrace () Running Mkbootstrap for XS () chmod 644 "LeakTrace.bs" chmod 644 "XS.bs" "/home/rg8239/perl/bin/perl" "-Iinc" -MExtUtils::Command::MM -e 'cp_no +nempty' -- LeakTrace.bs blib/arch/auto/Test/LeakTrace/LeakTrace.bs 64 +4 "/home/rg8239/perl/bin/perl" -MExtUtils::Command::MM -e 'cp_no +nempty' -- XS.bs blib/arch/auto/List/MoreUtils/XS/XS.bs 644 "/home/rg8239/perl/bin/perl" "-Iinc" "/home/rg8239/perl/lib/5.30.3/Ext +Utils/xsubpp" -typemap '/home/rg8239/perl/lib/5.30.3/ExtUtils/typema +p' LeakTrace.xs > LeakTrace.xsc "/home/rg8239/perl/bin/perl" "/home/rg8239/perl/lib/5.30.3/Ext +Utils/xsubpp" -typemap '/home/rg8239/perl/lib/5.30.3/ExtUtils/typema +p' XS.xs > XS.xsc mv LeakTrace.xsc LeakTrace.c mv XS.xsc XS.c gcc -c -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFI +LE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"0.16\" -DXS_VERSI +ON=\"0.16\" -fPIC "-I/home/rg8239/perl/lib/5.30.3/x86_64-linux/CORE" + LeakTrace.c gcc -c -I. -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFI +LE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"0.428\" -DXS_VERSI +ON=\"0.428\" -fPIC "-I/home/rg8239/perl/lib/5.30.3/x86_64-linux/CORE" + XS.c rm -f blib/arch/auto/Test/LeakTrace/LeakTrace.so rm -f blib/arch/auto/List/MoreUtils/XS/XS.so gcc -shared -O2 -L/usr/local/lib LeakTrace.o -o blib/arch/auto/Test +/LeakTrace/LeakTrace.so \ gcc -shared -O2 -L/usr/local/lib XS.o -o blib/arch/auto/List +/MoreUtils/XS/XS.so \ \ \ chmod 755 blib/arch/auto/Test/LeakTrace/LeakTrace.so chmod 755 blib/arch/auto/List/MoreUtils/XS/XS.so Manifying 3 pod documents Manifying 1 pod document LEEJO/Test-LeakTrace-0.16.tar.gz REHSACK/List-MoreUtils-XS-0.428.tar.gz /usr/bin/make -- OK /usr/bin/make -- OK [download] In both cases we see the same process, and the same flags - yet one results in a runtime mismatch and the other doesn't. The L::MU::XS build inserts a `-I.` in a couple of spots (needed to load headers that are located in the L::MU::XS top-level source directory), and the T::LT build inserts a `"-Iinc"` in a couple of spots - but I don't see anything telling in those minor differences. And, apart from those 2 minor discrepancies, the builds are identical. How can one module incur a mismatch, and the other not ? Cheers, Rob	[reply] [d/l] [select]
Re^9: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000) by bliako (Monsignor) on Aug 04, 2020 at 15:49 UTC
Re^10: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000) by rgren925 (Beadle) on Aug 04, 2020 at 23:35 UTC
Some notes below your chosen depth have not been shown here

In Section Seekers of Perl Wisdom