objdump: file format not recognized

[matth45]

Can someone tell me what is going on here?

This works fine for most libraries:

$ objdump -f /usr/lib64/libm.so

/usr/lib64/libm.so:     file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0000000000003ea0

$ objdump -f /usr/lib/libm.so

/usr/lib/libm.so:     file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00003470

However, for some libraries (with debugging info? from glibc-devel?) this fails:

$ objdump -f /usr/lib64/libc.so 
objdump: /usr/lib64/libc.so: File format not recognized

$ rpm -q --whatprovides /usr/lib64/libc.so
glibc-devel-2.13-1.x86_64

$ objdump -f /usr/lib64/libpthread.so
objdump: /usr/lib64/libpthread.so: File format not recognized

$ rpm -q --whatprovides /usr/lib64/libpthread.so 
glibc-devel-2.13-1.x86_64

But...

$ objdump -f /lib64/libpthread.so.0 

/lib64/libpthread.so.0:     file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0000000000005b80

$ objdump -f /lib64/libc.so.6 

/lib64/libc.so.6:     file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000000000001ef70

$ rpm -q --whatprovides /lib64/libc.so.6
glibc-2.13-1.x86_64

It's not just 64-bit libs, the same is true for 32-bit. It's not a corrupted file, or at least, this is the exact binary file that glibc-devel provides.

Is this a bug or an expected result? If I don't hear anything here I'll submit a bug.

[giulix]

I'd say expected:

[root@localhost ~]# file /usr/lib/libc.so
/usr/lib/libc.so: ASCII C program text
[root@localhost ~]# cat /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux.so.2 ) )
[root@localhost ~]# objdump -f /lib/libc.so.6

/lib/libc.so.6:     file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x003f6f70

I think it's related to linker scripts

[SiliconSlick]

libc.so.Xis neat/special in that you can execute it to find its version... a feature that would be cool for all libs if there wasn't an impact (which there probably is).

$ /lib64/libc.so.6 
GNU C Library stable release version 2.13, by Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.5.1 20100924 (Red Hat 4.5.1-4).
Compiled on a Linux 2.6.35 system on 2011-01-20.
Available extensions:
	Support for some architectures added on, not maintained in glibc core.
	The C stubs add-on version 2.1.2.
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	BIND-8.2.3-T5B
	RT using linux kernel aio
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

Definitely not a bug though... its been that way for ages.

SS

[jpollard]

objdump is designed to dump object files.

Not shared libraries (*.so files). These are not object files.

Not libraries (such as /usr/lib64/libieee.a), these are not object files either.

Object files are the output of compilers (*.o files), and contain a LOT
of information that is stripped out by linkers when they create shared
libraries or executable binaries.

Libraries are created with ar (*.a files), and are in a tar like file structure
with symbol names in index sections that allow the linker to identify
included *.o modules (these are object files) to include in a binary.

[matth45]

Thanks for the pointers everyone. I did not know that about linker scripts.

jpollard, objdump certainly is designed to handle .so files. 1) it works when you give it a real .so file and not a text file!, 2) the man page references dynamic objects and shared libraries.

[jpollard]

learn something new every day.