statically linked shared object? Or a corrupt file?

Question

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.

Answer 1

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?