I have a library that I got from a proprietary source and I'm trying to link against it but I'm getting the following error
libxxx.so: file not recognized: File format not recognized collect2: ld returned 1 exit status
and indeed
$ ldd ./libxxx.so
statically linked
what does that exactly mean? Never saw a statically linked .so in my life. It might be worth noting that the last version of the same software included the same .so for which ldd shows the "normal" output and that works fine.
$ file ./libxxx.so
./libxxx.so: ELF 32-bit LSB shared object, Intel 80386, version 1
(SYSV), stripped
but nm, objdump also can't see anything and readelf returns errors reading string table. Am I safe to assume this .so is botched or there is something else I can try before going to "enterprise support" and waiting for two months for them to acknowledge my existence.
$ objdump -a libxxx.so
objdump: libxxx.so: File format not recognized
$ readelf -a libxxx.so
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x4f00
Start of program headers: 52 (bytes into file)
Start of section headers: 147936 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 4
Size of section headers: 40 (bytes)
Number of section headers: 29
Section header string table index: 26
readelf: Error: Unable to read in 0xb70000 bytes of string table
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] <no-name> <unknown>: b400 08e40000 020000 000000 b0000 xo 262144 262144 2162688
[ 1] <no-name> <unknown>: 9980 13000000 030000 1a0000 30000 xo 262144 1048576 2686976
[ 2] <no-name> <unknown>: 1c98 13ad0000 000000 000000 ffff0000 xop 65536 0 3211264
[ 3] <no-name> <unknown>: 3046 02600000 020000 000000 fffe0000 xxop 131072 131072 4063232
[ 4] <no-name> <unknown>: 32a8 00400000 030000 010000 90000 xop 262144 0 5046272
[ 5] <no-name> <unknown>: 32e8 12c00000 020000 000000 90000 xop 262144 524288 5636096
[ 6] <no-name> <unknown>: 45a8 03100000 020000 090000 10000 xop 262144 524288 6225920
[ 7] <no-name> <unknown>: 48b8 00170000 000000 000000 10000 xop 262144 0 5898240
[ 8] <no-name> <unknown>: 48d0 06300000 000000 000000 10000 op 262144 262144 6619136
[ 9] <no-name> <unknown>: 4f00 59740000 000001 000000 10000 op 1048576 0 7012352
[10] <no-name> LOUSER+28740000 001a0001 000000 000000 10000 Wxop 262144 0 7405568
[11] <no-name> LOUSER+28a00000 7bb60001 000000 000000 10000 Wop 2097152 0 7929856
[12] <no-name> <unknown>: 3000 09900002 000000 000000 10000 Ap 2097152 0 8323072
[13] <no-name> <unknown>: 3990 00040002 000000 000000 60000 Aop 262144 0 8978432
[14] <no-name> <unknown>: 3994 00d80002 030000 000000 10000 Axop 262144 524288 9568256
[15] <no-name> <unknown>: 3a6c 00080002 000000 000000 10000 Axxop 262144 0 10027008
[16] <no-name> <unknown>: 3a74 00080002 000000 000000 10000 Axop 262144 0 10485760
[17] <no-name> <unknown>: 3a7c 00040002 000000 000000 10000 Axxop 262144 0 10813440
[18] <no-name> <unknown>: 3a80 020c0002 000000 000000 80000 Aop 262144 262144 11141120
[19] <no-name> <unknown>: 3c8c 001c0002 000000 000000 10000 Axxop 262144 0 11468800
[20] <no-name> NULL 01ee0002 000000 000000 10000 xxop 65536 0 12058624
[21] <no-name> NULL 00580002 000000 000000 10000 op 524288 0 13041664
[22] <no-name> NULL 00fa0002 000000 000000 10000 xop 65536 0 13828096
[23] <no-name> NULL 00200002 000000 000000 10000 xop 65536 0 14745600
[24] <no-name> NULL 01000002 000000 000000 30000 xop 65536 0 1114112
[25] <no-name> NULL 00ed0002 000000 000000 20000 xop 65536 0 65536
[26] <no-name> NULL 1cd00002 1c0000 b70000 30000 xop 262144 1048576 589824
[27] <no-name> NULL 194d0002 000000 000000 00 xop 65536 0 0
[28] <no-name> NULL 00b40000 000000 030000 30000 1 160956416 0
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000000 0x00000000 0x22456 0x22456 R E 0x1000
LOAD 0x023000 0x00023000 0x00023000 0x00c8c 0x00ca8 RW 0x1000
readelf: Error: no .dynamic section in the dynamic segment
DYNAMIC 0x023994 0x00023994 0x00023994 0x000d8 0x000d8 RW 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
There is no dynamic section in this file.
There are no relocations in this file.
There are no unwind sections in this file.
No version information found in this file.
Am I safe to assume this .so is botched
Yes, a .so file without a .dynamic section is almost certainly botched.
Did someone do an ASCII ftp transfer on it?
来源：https://stackoverflow.com/questions/9939421/statically-linked-shared-object-or-a-corrupt-file