readelf/ldconfig confused about ELF header

[Hamish Moffatt]

I'm using buildroot to compile for armeb on a x86-64 (little-endian) host.
uclibc's readelf and ldconfig are giving confusing results reading the
headers of compiled libraries. 

Programs run ok, but ldconfig decides that my target has mixed
byte-order libraries and generates a wrong-endianness ld.so.conf.

readelf says the right things for uClibc's own libraries:

[ 5:00PM] hamish at bach:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-uclibcgnu-readelf -h libdl.so.0 
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 61 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x788
  Start of program headers:          52 (bytes into file)
  Start of section headers:          8332 (bytes into file)
  Flags:                             0x202, has entry point, GNU EABI, software FP
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         6
  Size of section headers:           40 (bytes)
  Number of section headers:         16
  Section header string table index: 15

(although the GNU EABI part is not correct AFAICT). However for some reason for
the libraries built by ext2fsprogs,

[ 5:04PM] hamish at bach:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-uclibcgnu-readelf -h libe2p.so      
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x1db0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          22704 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         5
  Size of section headers:           64 (bytes)
  Number of section headers:         25
  Section header string table index: 24

However, objdump -p says the right things for this same library,
and I can run the programs linked to it ok.

[ 5:05PM] hamish at bach:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-objdump -p libe2p.so.2.3 

libe2p.so.2.3:     file format elf32-bigarm

Program Header:
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15
         filesz 0x00003afc memsz 0x00003afc flags r-x
    LOAD off    0x00004000 vaddr 0x0000c000 paddr 0x0000c000 align 2**15
         filesz 0x000003ac memsz 0x000005a4 flags rw-
 DYNAMIC off    0x00004014 vaddr 0x0000c014 paddr 0x0000c014 align 2**2
         filesz 0x000000d0 memsz 0x000000d0 flags rw-

Dynamic Section:
  NEEDED      libgcc_s.so.1
  NEEDED      libc.so.0
  SONAME      libe2p.so.2
  INIT        0xef8
  FINI        0x3044
  HASH        0x94
  STRTAB      0x7ac
  SYMTAB      0x2dc
  STRSZ       0x32f
  SYMENT      0x10
  PLTGOT      0xc0e4
  PLTRELSZ    0x150
  PLTREL      0x11
  JMPREL      0xda8
  REL         0xb98
  RELSZ       0x210
  RELENT      0x8
  VERNEED     0xb78
  VERNEEDNUM  0x1
  VERSYM      0xadc
  RELCOUNT    0x3b

Version References:
  required from libgcc_s.so.1:
    0x0b792650 0x00 02 GCC_3.0
private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]


I guess this means something is whacky in ext2fsprog's library generation?


thanks
Hamish
-- 
Hamish Moffatt VK3SB <hamish at debian.org> <hamish at cloud.net.au>