How can I easily find out the direct shared object dependencies of a Linux binary in ELF format?

I&#39;m aware of the ldd tool, but that appears to output all dependencies of a binary, including the dependencies of any shared objects that binary is dependent on.

Determine direct shared object dependencies of a Linux binary?

I have just installed CentOS 6 64bit version, I&#39;m trying to install a 32-bit application on a 64-bit machine and got this error:

&gt; /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

I&#39;m new to linux.  How do I resolve this?


CentOS 64 bit bad ELF interpreter

I was installing a binary Linux application on Ubuntu 9.10 x86_64. The app shipped with an old version of gzip (1.2.4), that was compiled for a much older kernel:

    $ file gzip 
    gzip: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped


I wasn&#39;t able to execute this program. If I tried, this happened:

    $ ./gzip
    -bash: ./gzip: No such file or directory

ldd was similarly unhappy with this binary:

    $ ldd gzip
            not a dynamic executable

I&#39;m curious: What&#39;s the most likely source of this problem? A corrupted file? Or a binary incompatibility due to being built for a much older {kernel,libc,...}? 

Per nos&#39;s suggestsions, here&#39;s the output of `strace ./gzip`:

    execve(&quot;./gzip&quot;, [&quot;./gzip&quot;], [/* 24 vars */]) = -1 ENOENT (No such file or directory)
    dup(2)                                  = 3
    fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
    fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa8c9eee000
    lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
    write(3, &quot;strace: exec: No such file or di&quot;..., 40strace: exec: No such file or directory
    ) = 40
    close(3)                                = 0
    munmap(0x7fa8c9eee000, 4096)            = 0
    exit_group(1)                           = ?

Here&#39;s the output of `readelf -a ./gzip`:

    ELF Header:
      Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
      Class:                             ELF32
      Data:                              2&#39;s complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              EXEC (Executable file)
      Machine:                           Intel 80386
      Version:                           0x1
      Entry point address:               0x8048d20
      Start of program headers:          52 (bytes into file)
      Start of section headers:          46852 (bytes into file)
      Flags:                             0x0
      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:         26
      Section header string table index: 25
    
    Section Headers:
      [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
      [ 0]                   NULL            00000000 000000 000000 00      0   0  0
      [ 1] .interp           PROGBITS        080480f4 0000f4 000013 00   A  0   0  1
      [ 2] .note.ABI-tag     NOTE            08048108 000108 000020 00   A  0   0  4
      [ 3] .hash             HASH            08048128 000128 000178 04   A  4   0  4
      [ 4] .dynsym           DYNSYM          080482a0 0002a0 000370 10   A  5   1  4
      [ 5] .dynstr           STRTAB          08048610 000610 0001ee 00   A  0   0  1
      [ 6] .gnu.version      VERSYM          080487fe 0007fe 00006e 02   A  4   0  2
      [ 7] .gnu.version_r    VERNEED         0804886c 00086c 000030 00   A  5   1  4
      [ 8] .rel.got          REL             0804889c 00089c 000008 08   A  4  20  4
      [ 9] .rel.bss          REL             080488a4 0008a4 000030 08   A  4  22  4
      [10] .rel.plt          REL             080488d4 0008d4 000158 08   A  4  12  4
      [11] .init             PROGBITS        08048a2c 000a2c 00002f 00  AX  0   0  4
      [12] .plt              PROGBITS        08048a5c 000a5c 0002c0 04  AX  0   0  4
      [13] .text             PROGBITS        08048d20 000d20 007f4c 00  AX  0   0 16
      [14] .fini             PROGBITS        08050c6c 008c6c 00001a 00  AX  0   0  4
      [15] .rodata           PROGBITS        08050ca0 008ca0 001751 00   A  0   0 32
      [16] .data             PROGBITS        08053400 00a400 000ab4 00  WA  0   0 32
      [17] .eh_frame         PROGBITS        08053eb4 00aeb4 000004 00  WA  0   0  4
      [18] .ctors            PROGBITS        08053eb8 00aeb8 000008 00  WA  0   0  4
      [19] .dtors            PROGBITS        08053ec0 00aec0 000008 00  WA  0   0  4
      [20] .got              PROGBITS        08053ec8 00aec8 0000bc 04  WA  0   0  4
      [21] .dynamic          DYNAMIC         08053f84 00af84 0000a0 08  WA  5   0  4
      [22] .bss              NOBITS          08054040 00b040 050630 00  WA  0   0 32
      [23] .comment          PROGBITS        00000000 00b040 000487 00      0   0  1
      [24] .note             NOTE            00000487 00b4c7 00017c 00      0   0  1
      [25] .shstrtab         STRTAB          00000000 00b643 0000be 00      0   0  1
    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
      PHDR           0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4
      INTERP         0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R   0x1
          [Requesting program interpreter: /lib/ld-linux.so.2]
      LOAD           0x000000 0x08048000 0x08048000 0x0a3f1 0x0a3f1 R E 0x1000
      LOAD           0x00a400 0x08053400 0x08053400 0x00c24 0x51270 RW  0x1000
      DYNAMIC        0x00af84 0x08053f84 0x08053f84 0x000a0 0x000a0 RW  0x4
      NOTE           0x000108 0x08048108 0x08048108 0x00020 0x00020 R   0x4
    
     Section to Segment mapping:
      Segment Sections...
       00     
       01     .interp 
       02     .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.got .rel.bss .rel.plt .init .plt .text .fini .rodata 
       03     .data .eh_frame .ctors .dtors .got .dynamic .bss 
       04     .dynamic 
       05     .note.ABI-tag 
    
    Dynamic section at offset 0xaf84 contains 20 entries:
      Tag        Type                         Name/Value
     0x00000001 (NEEDED)                     Shared library: [libc.so.6]
     0x0000000c (INIT)                       0x8048a2c
     0x0000000d (FINI)                       0x8050c6c
     0x00000004 (HASH)                       0x8048128
     0x00000005 (STRTAB)                     0x8048610
     0x00000006 (SYMTAB)                     0x80482a0
     0x0000000a (STRSZ)                      474 (bytes)
     0x0000000b (SYMENT)                     16 (bytes)
     0x00000015 (DEBUG)                      0x0
     0x00000003 (PLTGOT)                     0x8053ec8
     0x00000002 (PLTRELSZ)                   344 (bytes)
     0x00000014 (PLTREL)                     REL
     0x00000017 (JMPREL)                     0x80488d4
     0x00000011 (REL)                        0x804889c
     0x00000012 (RELSZ)                      56 (bytes)
     0x00000013 (RELENT)                     8 (bytes)
     0x6ffffffe (VERNEED)                    0x804886c
     0x6fffffff (VERNEEDNUM)                 1
     0x6ffffff0 (VERSYM)                     0x80487fe
     0x00000000 (NULL)                       0x0
    
    Relocation section &#39;.rel.got&#39; at offset 0x89c contains 1 entries:
     Offset     Info    Type            Sym.Value  Sym. Name
    08053f80  00000106 R_386_GLOB_DAT    00000000   __gmon_start__
    
    Relocation section &#39;.rel.bss&#39; at offset 0x8a4 contains 6 entries:
     Offset     Info    Type            Sym.Value  Sym. Name
    08054040  00000505 R_386_COPY        08054040   stdout
    08054044  00002705 R_386_COPY        08054044   stderr
    08054048  00000805 R_386_COPY        08054048   __ctype_b
    0805404c  00001f05 R_386_COPY        0805404c   stdin
    08054050  00001005 R_386_COPY        08054050   optarg
    08054054  00001e05 R_386_COPY        08054054   optind
    
    Relocation section &#39;.rel.plt&#39; at offset 0x8d4 contains 43 entries:
     Offset     Info    Type            Sym.Value  Sym. Name
    08053ed4  00000307 R_386_JUMP_SLOT   08048a6c   chown
    08053ed8  00003407 R_386_JUMP_SLOT   08048a7c   __register_frame_info
    08053edc  00001907 R_386_JUMP_SLOT   08048a8c   write
    08053ee0  00002e07 R_386_JUMP_SLOT   08048a9c   fileno
    08053ee4  00002607 R_386_JUMP_SLOT   08048aac   strcmp
    08053ee8  00003507 R_386_JUMP_SLOT   08048abc   close
    08053eec  00000d07 R_386_JUMP_SLOT   08048acc   perror
    08053ef0  00001a07 R_386_JUMP_SLOT   08048adc   fprintf
    08053ef4  00000907 R_386_JUMP_SLOT   08048aec   getenv
    08053ef8  00002007 R_386_JUMP_SLOT   08048afc   signal
    08053efc  00001207 R_386_JUMP_SLOT   08048b0c   fflush
    08053f00  00002407 R_386_JUMP_SLOT   08048b1c   unlink
    08053f04  00002a07 R_386_JUMP_SLOT   08048b2c   __errno_location
    08053f08  00001407 R_386_JUMP_SLOT   08048b3c   chmod
    08053f0c  00000e07 R_386_JUMP_SLOT   08048b4c   malloc
    08053f10  00001d07 R_386_JUMP_SLOT   08048b5c   __deregister_frame_inf
    08053f14  00002907 R_386_JUMP_SLOT   08048b6c   __xstat
    08053f18  00000b07 R_386_JUMP_SLOT   08048b7c   fgets
    08053f1c  00002c07 R_386_JUMP_SLOT   08048b8c   __fxstat
    08053f20  00001507 R_386_JUMP_SLOT   08048b9c   __lxstat
    08053f24  00000a07 R_386_JUMP_SLOT   08048bac   __strtol_internal
    08053f28  00002207 R_386_JUMP_SLOT   08048bbc   strncmp
    08053f2c  00003007 R_386_JUMP_SLOT   08048bcc   __libc_start_main
    08053f30  00001c07 R_386_JUMP_SLOT   08048bdc   strcat
    08053f34  00000407 R_386_JUMP_SLOT   08048bec   printf
    08053f38  00001307 R_386_JUMP_SLOT   08048bfc   lseek
    08053f3c  00000c07 R_386_JUMP_SLOT   08048c0c   memcpy
    08053f40  00001607 R_386_JUMP_SLOT   08048c1c   strrchr
    08053f44  00001b07 R_386_JUMP_SLOT   08048c2c   ctime
    08053f48  00000707 R_386_JUMP_SLOT   08048c3c   getopt_long
    08053f4c  00003207 R_386_JUMP_SLOT   08048c4c   closedir
    08053f50  00002507 R_386_JUMP_SLOT   08048c5c   opendir
    08053f54  00003107 R_386_JUMP_SLOT   08048c6c   open
    08053f58  00002b07 R_386_JUMP_SLOT   08048c7c   exit
    08053f5c  00001807 R_386_JUMP_SLOT   08048c8c   calloc
    08053f60  00002d07 R_386_JUMP_SLOT   08048c9c   _IO_putc
    08053f64  00003607 R_386_JUMP_SLOT   08048cac   free
    08053f68  00000607 R_386_JUMP_SLOT   08048cbc   utime
    08053f6c  00000f07 R_386_JUMP_SLOT   08048ccc   isatty
    08053f70  00002307 R_386_JUMP_SLOT   08048cdc   strncpy
    08053f74  00001107 R_386_JUMP_SLOT   08048cec   readdir
    08053f78  00002107 R_386_JUMP_SLOT   08048cfc   read
    08053f7c  00000207 R_386_JUMP_SLOT   08048d0c   strcpy
    
    There are no unwind sections in this file.
    
    Symbol table &#39;.dynsym&#39; contains 55 entries:
       Num:    Value  Size Type    Bind   Vis      Ndx Name
         0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
         1: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
         2: 08048d0c    34 FUNC    GLOBAL DEFAULT  UND strcpy@GLIBC_2.0 (3)
         3: 08048a6c   136 FUNC    GLOBAL DEFAULT  UND chown@GLIBC_2.1 (2)
         4: 08048bec    41 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.0 (3)
         5: 08054040     4 OBJECT  GLOBAL DEFAULT   22 stdout@GLIBC_2.0 (3)
         6: 08048cbc    59 FUNC    GLOBAL DEFAULT  UND utime@GLIBC_2.0 (3)
         7: 08048c3c    43 FUNC    GLOBAL DEFAULT  UND getopt_long@GLIBC_2.0 (3)
         8: 08054048     4 OBJECT  GLOBAL DEFAULT   22 __ctype_b@GLIBC_2.0 (3)
         9: 08048aec   224 FUNC    GLOBAL DEFAULT  UND getenv@GLIBC_2.0 (3)
        10: 08048bac  1106 FUNC    GLOBAL DEFAULT  UND __strtol_internal@GLIBC_2.0 (3)
        11: 08048b7c   202 FUNC    WEAK   DEFAULT  UND fgets@GLIBC_2.0 (3)
        12: 08048c0c    62 FUNC    GLOBAL DEFAULT  UND memcpy@GLIBC_2.0 (3)
        13: 08048acc   111 FUNC    GLOBAL DEFAULT  UND perror@GLIBC_2.0 (3)
        14: 08048b4c   338 FUNC    WEAK   DEFAULT  UND malloc@GLIBC_2.0 (3)
        15: 08048ccc    46 FUNC    WEAK   DEFAULT  UND isatty@GLIBC_2.0 (3)
        16: 08054050     4 OBJECT  GLOBAL DEFAULT   22 optarg@GLIBC_2.0 (3)
        17: 08048cec   142 FUNC    WEAK   DEFAULT  UND readdir@GLIBC_2.0 (3)
        18: 08048b0c   152 FUNC    WEAK   DEFAULT  UND fflush@GLIBC_2.0 (3)
        19: 08048bfc    61 FUNC    WEAK   DEFAULT  UND lseek@GLIBC_2.0 (3)
        20: 08048b3c    59 FUNC    WEAK   DEFAULT  UND chmod@GLIBC_2.0 (3)
        21: 08048b9c   314 FUNC    GLOBAL DEFAULT  UND __lxstat@GLIBC_2.0 (3)
        22: 08048c1c   441 FUNC    GLOBAL DEFAULT  UND strrchr@GLIBC_2.0 (3)
        23: 0804f608    29 FUNC    GLOBAL DEFAULT   13 basename
        24: 08048c8c   563 FUNC    WEAK   DEFAULT  UND calloc@GLIBC_2.0 (3)
        25: 08048a8c    61 FUNC    WEAK   DEFAULT  UND write@GLIBC_2.0 (3)
        26: 08048adc    36 FUNC    GLOBAL DEFAULT  UND fprintf@GLIBC_2.0 (3)
        27: 08048c2c    35 FUNC    GLOBAL DEFAULT  UND ctime@GLIBC_2.0 (3)
        28: 08048bdc    49 FUNC    GLOBAL DEFAULT  UND strcat@GLIBC_2.0 (3)
        29: 08048b5c   162 FUNC    WEAK   DEFAULT  UND __deregister_frame_info@GLIBC_2.0 (3)
        30: 08054054     4 OBJECT  GLOBAL DEFAULT   22 optind@GLIBC_2.0 (3)
        31: 0805404c     4 OBJECT  GLOBAL DEFAULT   22 stdin@GLIBC_2.0 (3)
        32: 08048afc   181 FUNC    WEAK   DEFAULT  UND signal@GLIBC_2.0 (3)
        33: 08048cfc    61 FUNC    WEAK   DEFAULT  UND read@GLIBC_2.0 (3)
        34: 08048bbc   148 FUNC    GLOBAL DEFAULT  UND strncmp@GLIBC_2.0 (3)
        35: 08048cdc   147 FUNC    GLOBAL DEFAULT  UND strncpy@GLIBC_2.0 (3)
        36: 08048b1c    55 FUNC    WEAK   DEFAULT  UND unlink@GLIBC_2.0 (3)
        37: 08048c5c   412 FUNC    WEAK   DEFAULT  UND opendir@GLIBC_2.0 (3)
        38: 08048aac    58 FUNC    GLOBAL DEFAULT  UND strcmp@GLIBC_2.0 (3)
        39: 08054044     4 OBJECT  GLOBAL DEFAULT   22 stderr@GLIBC_2.0 (3)
        40: 0804f7fc    40 FUNC    GLOBAL DEFAULT   13 error
        41: 08048b6c   314 FUNC    GLOBAL DEFAULT  UND __xstat@GLIBC_2.0 (3)
        42: 08048b2c    27 FUNC    WEAK   DEFAULT  UND __errno_location@GLIBC_2.0 (3)
        43: 08048c7c   200 FUNC    GLOBAL DEFAULT  UND exit@GLIBC_2.0 (3)
        44: 08048b8c   314 FUNC    GLOBAL DEFAULT  UND __fxstat@GLIBC_2.0 (3)
        45: 08048c9c   150 FUNC    GLOBAL DEFAULT  UND _IO_putc@GLIBC_2.0 (3)
        46: 08048a9c    53 FUNC    GLOBAL DEFAULT  UND fileno@GLIBC_2.0 (3)
        47: 08050ca4     4 OBJECT  GLOBAL DEFAULT   15 _IO_stdin_used
        48: 08048bcc   261 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.0 (3)
        49: 08048c6c    61 FUNC    WEAK   DEFAULT  UND open@GLIBC_2.0 (3)
        50: 08048c4c   112 FUNC    WEAK   DEFAULT  UND closedir@GLIBC_2.0 (3)
        51: 0804f824    66 FUNC    GLOBAL DEFAULT   13 warn
        52: 08048a7c   116 FUNC    WEAK   DEFAULT  UND __register_frame_info@GLIBC_2.0 (3)
        53: 08048abc    55 FUNC    WEAK   DEFAULT  UND close@GLIBC_2.0 (3)
        54: 08048cac   202 FUNC    WEAK   DEFAULT  UND free@GLIBC_2.0 (3)
    
    Histogram for bucket list length (total of 37 buckets):
     Length  Number     % of total  Coverage
          0  10         ( 27.0%)
          1  14         ( 37.8%)     25.9%
          2  4          ( 10.8%)     40.7%
          3  4          ( 10.8%)     63.0%
          4  5          ( 13.5%)    100.0%
    
    Version symbols section &#39;.gnu.version&#39; contains 55 entries:
     Addr: 00000000080487fe  Offset: 0x0007fe  Link: 4 (.dynsym)
      000:   0 (*local*)       0 (*local*)       3 (GLIBC_2.0)     2 (GLIBC_2.1)  
      004:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
      008:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
      00c:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
      010:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
      014:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     1 (*global*)   
      018:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
      01c:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
      020:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
      024:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
      028:   1 (*global*)      3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
      02c:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     1 (*global*)   
      030:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)     1 (*global*)   
      034:   3 (GLIBC_2.0)     3 (GLIBC_2.0)     3 (GLIBC_2.0)  
    
    Version needs section &#39;.gnu.version_r&#39; contains 1 entries:
     Addr: 0x000000000804886c  Offset: 0x00086c  Link: 5 (.dynstr)
      000000: Version: 1  File: libc.so.6  Cnt: 2
      0x0010:   Name: GLIBC_2.0  Flags: none  Version: 3
      0x0020:   Name: GLIBC_2.1  Flags: none  Version: 2
    
    Notes at offset 0x00000108 with length 0x00000020:
      Owner         Data size       Description
      GNU           0x00000010      NT_GNU_ABI_TAG (ABI version tag)
    
    Notes at offset 0x0000b4c7 with length 0x0000017c:
      Owner         Data size       Description
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)
      01.01         0x00000000      NT_VERSION (version)



&quot;No such file or directory&quot; error when executing a binary

How do I install GCC (the GNU Compiler Collection) piece by piece, using the current version,  
using the correct versions of dependencies, not using a package manager (like yum, rpm, apt, dpkg), and not using shared libraries?

Typical developers will likely want to install GCC the typical way, use your package manager (yum, rpm, apt, dpkg, port, brew, etc.) or follow the instructions here (http://gcc.gnu.org/wiki/InstallingGCC).

My question is how to install GCC piece by piece, without shared libraries.

* I want a fully-independent GCC that can be moved around my system without using any shared libraries, and without creating any shared libraries.
* This is what GCC calls &quot;the difficult way&quot; and it is not recommended for typical users.

GCC depends on:

  * GMP: GNU Multiple Precision Arithmetic Library
  * MPFR: GNU Multiple-precision floating-point rounding library
  * MPC: GNU Multiple-precision C library
  * ELF: Executable and Linkable Format library
  * PPL: Parma Polyhedra Library (optional, for memory optimizations)


How to install GCC piece by piece with GMP, MPFR, MPC, ELF, without shared libraries?

I have an old executable that&#39;s scheduled for the scrap heap, but it&#39;s not there yet. It relies on some libs that have been removed from my environment, but I have some stub libs someplace where it works fine. Id like to point this executable to these stub libs. Yes, i could set LD_LIBRARY_PATH, but this executable is called from many scripts, and many users and I&#39;d love to fix it in one spot.

I don&#39;t have source for this, and would be hard to get it. I was thinking - can I edit this file, using an ELF aware editor, and add a simple PATH to rpath to have it hit the new libs? Is this possible, or once you create an ELF binary, you fix things to locations and they can&#39;t be moved?

Can I change &#39;rpath&#39; in an already compiled binary?

The final images produced by compliers contain both bin file and extended loader format ELf file ,what is the difference between the two , especially the utility of ELF file.

What is the difference between ELF files and bin files?

I&#39;m working on a nodejs project for school.
I wasn&#39;t able to install bcrypt with npm so i installed bcrypt-nodejs and the project worked fine yesterday.
But today, when I do a &quot;node app&quot; i have this error :


    /.../node_modules/bcrypt/node_modules/bindings/bindings.js:79
            throw e
                  ^
    Error: /.../node_modules/bcrypt/build/Release/bcrypt_lib.node: invalid ELF header
        at Module.load (module.js:356:32)
        at Function.Module._load (module.js:312:12)
        at Module.require (module.js:364:17)
        at require (module.js:380:17)
        at bindings (/.../node_modules/bcrypt/node_modules/bindings/bindings.js:74:15)
        at Object.&lt;anonymous&gt; (/.../node_modules/bcrypt/bcrypt.js:1:97)
        at Module._compile (module.js:456:26)
        at Object.Module._extensions..js (module.js:474:10)
        at Module.load (module.js:356:32)
        at Function.Module._load (module.js:312:12)
        at Module.require (module.js:364:17)
        at require (module.js:380:17)

my package.json file looks like this:


    {
      &quot;name&quot;: &quot;Supinfarm&quot;,
      &quot;version&quot;: &quot;0.0.0&quot;,
      &quot;env&quot;: {
                  &quot;PYTHON&quot;: &quot;/usr/bin/python2.6&quot;
            },
      &quot;dependencies&quot;: {
        &quot;express&quot;: &quot;3.1.0&quot;,
        &quot;connect-flash&quot;: &quot;*&quot;,
        &quot;jade&quot;: &quot;*&quot;,
        &quot;stylus&quot;: &quot;*&quot;,
        &quot;passport&quot;: &quot;*&quot;,
        &quot;passport-local&quot;: &quot;*&quot;,
        &quot;mongoose&quot;: &quot;*&quot;,
        &quot;bcrypt&quot;: &quot;*&quot;
      }
    }

I&#39;m on Linux ubuntu 10.04 LTS
I&#39;ve tried to find a solution on google without success...
Can somebody help me?


bcrypt invalid elf header when running node app

I&#39;ve got a binary installed on my system, and would like to look at the disassembly of a given function. Preferrably using `objdump`, but other solutions would be acceptable as well.

From [this questions][1] I&#39;ve learned that I might be able to disassemble part of the code if I only know the boundary addresses. From [this answer][2] I&#39;ve learned how to turn my split debug symbols back into a single file.

But even operating on that single file, and even disassembling all the code (i.e. without start or stop address, but plain `-d` parameter to `objdump`), I still don&#39;t see that symbol anywhere. Which makes sense insofar as the function in question is static, so it isn&#39;t exported. Nevertheless, `valgrind` will report the function name, so it has to be stored somewhere. 

Looking at the details of the debug sections, I find that name mentioned in the `.debug_str` section, but I don&#39;t know a tool which can turn this into an address range.


  [1]: https://stackoverflow.com/q/6441721/1468366
  [2]: https://stackoverflow.com/a/17599967/1468366

How to disassemble one single function using objdump?

Does anybody have an idea how to statically compile any resource file right into the executable or the shared library file using GCC?

For example I&#39;d like to add image files that never change (and if they do, I&#39;d have to replace the file anyway) and wouldn&#39;t want them to lie around in the file system.

If this is possible (and I think it is because Visual C++ for Windows can do this, too), how can I load the files which are stored in the own binary? Does the executable parse itself, find the file and extract the data out of it?

Maybe there&#39;s an option for GCC which I haven&#39;t seen yet. Using search engines didn&#39;t really spit out the right stuff.

I would need this to work for shared libraries and normal ELF-executables.

C/C++ with GCC: Statically add resource files to executable/library

From wiki [Executable and Linkable Format](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format):

&gt; The segments contain information that is necessary for runtime execution of the file, while sections contain important data for linking and relocation. Any byte in the entire file can be owned by at most one section, and there can be orphan bytes which are not owned by any section.

But what is the difference between section and segment? 
In an executable ELF file, does a segment contain one or more sections?

What&#39;s the difference of section and segment in ELF file format

I&#39;ve been using `objdump` to look at assembly code in Linux ELF binaries.

Sometimes there is an indirect jump through a jump table that is stored in the `rodata` (read-only data) section.

How to get `objdump` or any other tool to show me the contents of this data section?

I could execute the program and examine the relevant addresses in the debugger, but I don&#39;t want to do that because it has to be done interactively.

The ideal answer will identify a tool that will not only show me the contents but will let me control the display format, much as `od` does.

How can I examine contents of a data section of an ELF file on Linux?

I&#39;d like to retrieve the GCC version used to compile a given executable. I tried `readelf` but didn&#39;t get the information. Any thoughts?

How to retrieve the GCC version used to compile a given ELF executable?

What exactly does `-rdynamic` (or `--export-dynamic` at the linker level) do and how does it relate to symbol visibility as defined by the `-fvisibility*` flags or visibility `pragma`s and `__attribute__`s?

For `--export-dynamic`, [ld(1)][1] mentions:

&gt; ...
&gt; If you use &quot;dlopen&quot; to load a dynamic object which needs to refer back
&gt; to the symbols defined by the program, rather than some other dynamic
&gt; object, then you will probably need
&gt;            to use this option when linking the program itself. ...

I&#39;m not sure I completely understand this. Could you please provide an example that doesn&#39;t work without `-rdynamic` but does with it?


**Edit**: 
I actually tried compiling a couple of dummy libraries (single file, multi-file, various -O levels, some inter-function calls, some hidden symbols, some visible), with and without `-rdynamic`, and so far I&#39;ve been getting **byte-identical** outputs (when keeping all other flags constant of course), which is quite puzzling.

  [1]: http://linux.die.net/man/1/ld

What exactly does `-rdynamic` do and when exactly is it needed?

I am trying to build a simple C program for two different Linux environments. On one device the program runs fine, on the other device the program generates a floating point exception. The program does nothing but return 0 from main which leads me to believe there is some incompatibility with the start-up code perhaps ABI?

The program is compiled with gcc with the following build specs:

&gt; Using built-in specs. Target: i386-redhat-linux Configured with:
&gt; ../configure --prefix=/usr --mandir=/usr/share/man
&gt; --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)


The program source is the following:

    int main()
    {
            return(0);
    }

On the Celeron device this program generates the following under GDB:

    [root@n00200C30AA2F jrn]# /jrn/gdb fail GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) (gdb) run Starting program: /jrn/fail 
    
    Program received signal SIGFPE, Arithmetic exception. 0x40001cce in ?? () (gdb) bt
    #0  0x40001cce in ?? ()
    #1  0x4000c6b0 in ?? ()
    #2  0x40000cb5 in ?? ()

Below are the details that I can think to gather to help find out what is happening:

&lt;!-- language: none --&gt;

    CELERON:  ( fails on this device )
    2.6.8 #21 Mon Oct 1 11:41:47 PDT 2007 i686 i686 i386 GNU/Linux
    ============
    [root@n00200C30AA2F proc]# cat cpuinfo 
    processor       : 0
    vendor_id       : GenuineIntel
    cpu family      : 6
    model           : 9
    model name      : Intel(R) Celeron(R) M processor          600MHz
    stepping        : 5
    cpu MHz         : 599.925
    cache size      : 512 KB
    fdiv_bug        : no
    hlt_bug         : no
    f00f_bug        : no
    coma_bug        : no
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 2
    wp              : yes
    flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe
    bogomips        : 1179.64
    
    GNU C Library stable release version 2.3.2, by Roland McGrath et al.
    Compiled by GNU CC version 3.2.2 20030222 (Red Hat Linux 3.2.2-5).
    Compiled on a Linux 2.4.20 system on 2003-03-13.
    Available extensions:
            GNU libio by Per Bothner
            crypt add-on version 2.1 by Michael Glad and others
            linuxthreads-0.10 by Xavier Leroy
            BIND-8.2.3-T5B
            libthread_db work sponsored by Alpha Processor Inc
            NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
    
    ATOM:  ( works fine on this device )
    2.6.35 #25 SMP Mon Mar 12 09:02:45 PDT 2012 i686 i686 i386 GNU/Linux
    ==========
    [root@n00E04B36ECE5 ~]# cat /proc/cpuinfo 
    processor       : 0
    vendor_id       : GenuineIntel
    cpu family      : 6
    model           : 28
    model name      : Genuine Intel(R) CPU N270   @ 1.60GHz
    stepping        : 2
    cpu MHz         : 1599.874
    cache size      : 512 KB
    fdiv_bug        : no
    hlt_bug         : no
    f00f_bug        : no
    coma_bug        : no
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 10
    wp              : yes
    flags           : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc up arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm
    bogomips        : 3199.74
    clflush size    : 64
    cache_alignment : 64
    address sizes   : 32 bits physical, 32 bits virtual
    power management:
    
    
    GNU C Library stable release version 2.5, by Roland McGrath et al.
    Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44).
    Compiled on a Linux 2.6.9 system on 2009-09-02.
    Available extensions:
            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
            GNU libio by Per Bothner
            NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
            Native POSIX Threads Library by Ulrich Drepper et al
            BIND-8.2.3-T5B
            RT using linux kernel aio
    Thread-local storage support included.


What can I do to determine what is causing this problem?
How about trying to statically link against a certain version of libc?

After failure occurs under GDB I execute:

&gt;     (gdb) x/1i $eip
&gt;     0x40001cce:     divl   0x164(%ecx)
&gt; 

    (gdb) info reg
    eax            0x6c994f 7117135
    ecx            0x40012858       1073817688
    edx            0x0      0
    ebx            0x40012680       1073817216
    esp            0xbffff740       0xbffff740
    ebp            0xbffff898       0xbffff898
    esi            0x8049580        134518144
    edi            0x400125cc       1073817036
    eip            0x40001cce       0x40001cce
    eflags         0x10246  66118
    cs             0x73     115
    ss             0x7b     123
    ds             0x7b     123
    es             0x7b     123
    fs             0x0      0
    gs             0x0      0
    (gdb) x/1wx 0x164+$ecx
    0x400129bc:     0x00000000
    (gdb) 


Based on the help I&#39;ve received it appears that for some reason the libc startup code is dividing by 0. 

The question now is, what is causing this obviously bad behavior? Something must be incompatible with something else? 

**Assembly output:**

    [jrn@localhost ~]$ more fail.s
            .file   &quot;fail.c&quot;
            .text
    .globl main
            .type   main, @function
    main:
            leal    4(%esp), %ecx
            andl    $-16, %esp
            pushl   -4(%ecx)
            pushl   %ebp
            movl    %esp, %ebp
            pushl   %ecx
            movl    $0, %eax
            popl    %ecx
            popl    %ebp
            leal    -4(%ecx), %esp
            ret
            .size   main, .-main
            .ident  &quot;GCC: (GNU) 4.1.2 20080704 (Red Hat 4.1.2-52)&quot;
            .section        .note.GNU-stack,&quot;&quot;,@progbits

  




Floating point exception ( SIGFPE ) on &#39;int main(){ return(0); }&#39;

Got the following error when I tried to compile a C application in 64-bit FreeBSD:

&gt; relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC

What is `R_X86_64_32S` relocation and what is `R_X86_64_64`?

I&#39;ve googled about the error, and it&#39;s possible causes - It&#39;d be great if anyone could tell what R_X86_64_32S really means.


What do R_X86_64_32S and R_X86_64_64 relocation mean?

Test is on 32 bit x86 Linux with `gcc` 4.6.3

When using `gcc` to compile a `C` program and using `readelf` to check the section info, 
I can see the `.eh_frame` section and `.eh_frame_hdr` sections inside.

For example, here is the section info of binary program `Perlbench`.

    readelf -S perlbench

    There are 28 section headers, starting at offset 0x102e48:

    Section Headers:
    [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
    [ 0]                   NULL            00000000 000000 000000 00      0   0  0
    [ 1] .interp           PROGBITS        08048154 000154 000013 00   A  0   0  1
    [ 2] .note.ABI-tag     NOTE            08048168 000168 000020 00   A  0   0  4
    [ 3] .note.gnu.build-i NOTE            08048188 000188 000024 00   A  0   0  4
    [ 4] .gnu.hash         GNU_HASH        080481ac 0001ac 000044 04   A  5   0  4
    [ 5] .dynsym           DYNSYM          080481f0 0001f0 0007b0 10   A  6   1  4
    [ 6] .dynstr           STRTAB          080489a0 0009a0 0003d6 00   A  0   0  1
    [ 7] .gnu.version      VERSYM          08048d76 000d76 0000f6 02   A  5   0  2
    [ 8] .gnu.version_r    VERNEED         08048e6c 000e6c 0000a0 00   A  6   2  4
    [ 9] .rel.dyn          REL             08048f0c 000f0c 000028 08   A  5   0  4
    [10] .rel.plt          REL             08048f34 000f34 000388 08   A  5  12  4
    [11] .init             PROGBITS        080492bc 0012bc 00002e 00  AX  0   0  4
    [12] .plt              PROGBITS        080492f0 0012f0 000720 04  AX  0   0 16
    [13] .text             PROGBITS        08049a10 001a10 0cf86c 00  AX  0   0 16
    [14] .fini             PROGBITS        0811927c 0d127c 00001a 00  AX  0   0  4
    [15] .rodata           PROGBITS        081192a0 0d12a0 017960 00   A  0   0 32
    [16] .eh_frame_hdr     PROGBITS        08130c00 0e8c00 003604 00   A  0   0  4
    [17] .eh_frame         PROGBITS        08134204 0ec204 01377c 00   A  0   0  4
    [18] .ctors            PROGBITS        08148f0c 0fff0c 000008 00  WA  0   0  4
    [19] .dtors            PROGBITS        08148f14 0fff14 000008 00  WA  0   0  4
    [20] .jcr              PROGBITS        08148f1c 0fff1c 000004 00  WA  0   0  4
    [21] .dynamic          DYNAMIC         08148f20 0fff20 0000d0 08  WA  6   0  4
    [22] .got              PROGBITS        08148ff0 0ffff0 000004 04  WA  0   0  4
    [23] .got.plt          PROGBITS        08148ff4 0ffff4 0001d0 04  WA  0   0  4
    [24] .data             PROGBITS        081491e0 1001e0 002b50 00  WA  0   0 32
    [25] .bss              NOBITS          0814bd40 102d30 002b60 00  WA  0   0 32
    [26] .comment          PROGBITS        00000000 102d30 00002a 01  MS  0   0  1
    [27] .shstrtab         STRTAB          00000000 102d5a 0000ec 00      0   0  1
   

In my understanding, these two sections are used for handling exceptions, it produce tables that describe how to unwind the stack.

But it is for `C++` program, they use `eh_frame` and `gcc_exception_table` sections to manage exceptions, then why does compiler put the `eh_frame` and `eh_frame_hdr` sections inside `ELF` compiled from `C` program?



Why GCC compiled C program needs .eh_frame section?

Could someone explain the columns shown of the symbol table using `readelf`?

What are the meanings of the columns of the symbol table displayed by readelf?

When you build a gcc toolchain there is the possibility to build it as  arm-elf or as arm-none-eabi, but what is the difference? 

I use the eabi today, but that is just since everyone else seem to do that... but since that is a really bad argument, it would be really nice to understand the difference.

Note: This toolchain will crosscompile code for Cortex-M3 based mcu:s like the stm32.

Thanks

----

**Some links**:

EABI:

* http://en.wikipedia.org/wiki/Application_binary_interface
* http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html

ELF: 

* http://en.wikipedia.org/wiki/Executable_and_Linkable_Format

arm gcc toolchain as arm-elf or arm-none-eabi, what is the difference?

I need to learn about the ELF file layout for a project I am working on and I noticed the existence of these tools.
Why do all Linux distributions include both readelf and objdump? Do these tools complement one another? When would i prefer to use one over another?

All Elf Solutions on Gang of Coders

Total of 19 Elf Solutions