具有“System V”和“Linux”ABI 的 ELF 二进制文件是否相互兼容？

Question

TL;DR: My binary is unable to load /lib64/libm.so, and I don't know why. Peering at the elves' fuzzy little headers, the only thing that looks like an incompatibility is the ABI number.

Long form: Test run bombs claiming the binary is not found - but it exists.

[aardvark@aardvark-burrow ~/project-src] ldd  /data/users/aardvark/project-src/buck-out/gen/arvr/libraries/perception/calib/metrics/metrics_test
/data/users/aardvark/project-src/buck-out/gen/arvr/libraries/perception/calib/metrics/metrics_test: error while loading shared libraries: /lib64/libc.so: invalid ELF header

cat-ing /lib64/libm.so reveals:

/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libm.so.6  AS_NEEDED ( /usr/lib64/libmvec_nonshared.a /lib64/libmvec.so.1 ) )

Following the links to the bitter end, I get an ELF file. I read the header for that and for the binary which needs it, stuff 'em into text files, and diff those:

[aardvark@aardvark-burrow ~/project-src] diff ~/logs/elf.ray_transport_test.txt ~/logs/elf.libm.txt 
--- /home/aardvark/logs/elf.ray_transport_test.txt  2021-12-06 11:34:40.843179878 -0800
+++ /home/aardvark/logs/elf.libm.txt    2021-12-06 11:33:50.264101198 -0800
@@ -1,20 +1,20 @@
 ELF Header:
-  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
+  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
   Class:                             ELF64
   Data:                              2's complement, little endian
   Version:                           1 (current)
-  OS/ABI:                            UNIX - System V
+  OS/ABI:                            UNIX - GNU 
   ABI Version:                       0
   Type:                              DYN (Shared object file)
   Machine:                           Advanced Micro Devices X86-64
   Version:                           0x1
-  Entry point address:               0x13220
+  Entry point address:               0xc520
   Start of program headers:          64 (bytes into file)
-  Start of section headers:          15936800 (bytes into file)
+  Start of section headers:          2189472 (bytes into file)
   Flags:                             0x0
   Size of this header:               64 (bytes)
   Size of program headers:           56 (bytes)
   Number of program headers:         9
   Size of section headers:           64 (bytes)
-  Number of section headers:         40
-  Section header string table index: 39
+  Number of section headers:         37
+  Section header string table index: 36

My VM id's itself through uname -a thus:

Linux aardvark-burrow.zoo.com 5.6.13-0_fbk17_hardened_5815_gc01d8dbd2635 #1 SMP Fri Jul 9 10:54:31 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux

Is this why my executable is failing?

What else could be the problem?

Answer 1

Your error message refers to /lib64/libc.so , not /lib64/libm.so .

It looks like something is trying to load libc.so (and libm.so ) instead of loading libc.so.6 (and libm.so.6 ).

Since the .so files are not ELF (they are linker scripts), of course trying to load them fails.

Assuming that the load is happening because readelf -d metrics_test | grep NEEDED | egrep 'lib(c|m)\.so$ readelf -d metrics_test | grep NEEDED | egrep 'lib(c|m)\.so$ readelf -d metrics_test | grep NEEDED | egrep 'lib(c|m)\.so$ is non-empty, the problem is that metrics_test is not linked correctly.

In particular, when metrics_test was linked, it picked up some non-linker-script version of libc.so and libm.so .

You can use -Wl,-t at link time to find out which libc.so and libm.so the linker picked up.