This might sound like a silly question but If you have a thirdParty.framework file, can you tell if it&#39;s static or dynamic? I mean, do they look different if you look inside?

iOS is it a static or a dynamic framework?

I often hear the terms &#39;statically linked&#39; and &#39;dynamically linked&#39;, often in reference to code written in [C][1], [C++][2] or [C#][3]. What are they, what exactly are they talking about, and what are they linking?

  [1]: http://en.wikipedia.org/wiki/C_%28programming_language%29
  [2]: https://en.wikipedia.org/wiki/C++
  [3]: http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29


What do &#39;statically linked&#39; and &#39;dynamically linked&#39; mean?

I&#39;ve always wondered. I know that compilers convert the code you write into binaries but what do linkers do? They&#39;ve always been a mystery to me. 

I roughly understand what &#39;linking&#39; is. It is when references to libraries and frameworks are added to the binary. I don&#39;t understand anything beyond that. For me it &quot;just works&quot;. I also understand the basics of dynamic linking but nothing too deep.

Could someone explain the terms?

What do linkers do?

It feels  strange to me to use `-Wl,-Bstatic` in order to tell `gcc` which libraries I want to link with statically. After all I&#39;m telling `gcc` directly all other information about linking with libraries (`-Ldir`, `-llibname`).

Is it possible to tell the gcc driver directly which libraries should be linked statically?

**Clarification:** I know that if a certain library exists only in static versions it&#39;ll use it  without `-Wl,-Bstatic`, but I want to imply `gcc` to prefer the static library. I also know that specifying the library file directly would link with it, but I prefer to keep the semantic for including static and dynamic libraries the same.

Telling gcc directly to link a library statically

I&#39;m trying to understand what happens when modules with globals and static variables are dynamically linked to an application. 
By modules, I mean each project in a solution (I work a lot with visual studio!). These modules are either built into *.lib or *.dll or the *.exe itself.

I understand that the binary of an application contains global and static data of all the individual translation units (object files) in the data segment (and read only data segment if const).

- What happens when this application uses a module A with load-time dynamic linking? I assume the DLL has a section for its globals and statics. Does the operating system load them? If so, where do they get loaded to?

- And what happens when the application uses a module B with run-time dynamic linking?

- If I have two modules in my application that both use A and B, are copies of A and B&#39;s globals created as mentioned below (if they are different processes)?

- Do DLLs A and B get access to the applications globals?

(Please state your reasons as well)

Quoting from [MSDN]:

&gt; Variables that are declared as global in a DLL source code file are treated as global variables by the compiler and linker, but each process that loads a given DLL gets its own copy of that DLL&#39;s global variables. The scope of static variables is limited to the block in which the static variables are declared. As a result, each process has its own instance of the DLL global and static variables by default.


and from [here][1]:

&gt; When dynamically linking modules, it can be unclear whether different libraries have their own instances of globals or whether the globals are shared.


  [MSDN]: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682594%28v=vs.85%29.aspx


  [1]: http://c2.com/cgi/wiki?GlobalVariablesAreBad

Thanks.

What happens to global and static variables in a shared library when it is dynamically linked?

I am trying to create a static object written in Go to interface with a C program (say, a kernel module or something).

I have found documentation on calling C functions from Go, but I haven&#39;t found much on how to go the other way.  What I&#39;ve found is that it&#39;s possible, but complicated.

Here is what I found:

[Blog post about callbacks between C and Go](http://cheesesun.blogspot.com/2010/04/callbacks-in-cgo.html)

[Cgo documentation](http://golang.org/cmd/cgo/)

[Golang mailing list post](http://groups.google.com/group/golang-nuts/browse_thread/thread/4de85861de6ef204/f7d610e08b86d437?lnk=gst&amp;q=cgo+dynamic+linking+D#f7d610e08b86d437)

Does anyone have experience with this? In short, I&#39;m trying to create a PAM module written entirely in Go.

Call Go functions from C

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

When creating a class library in C++, you can choose between dynamic (`.dll`, `.so`) and static (`.lib`, `.a`) libraries. What is the difference between them and when is it appropriate to use which?

When to use dynamic vs. static libraries

Are there any compelling performance reasons to choose static linking over dynamic linking or vice versa in certain situations? I&#39;ve heard or read the following, but I don&#39;t know enough on the subject to vouch for its veracity.

1) The difference in runtime performance between static linking and dynamic linking is usually negligible.

2) (1) is not true if using a profiling compiler that uses profile data to optimize program hotpaths because with static linking, the compiler can optimize both your code and the library code. With dynamic linking only your code can be optimized. If most of the time is spent running library code, this can make a big difference. Otherwise, (1) still applies.

Static linking vs dynamic linking

    0x00000000004004b6 &lt;main+30&gt;:	callq  0x400398 &lt;printf@plt&gt;


Anyone knows?


**UPDATE**

Why two `disas printf` give me different result?

    (gdb) disas printf
    Dump of assembler code for function printf@plt:
    0x0000000000400398 &lt;printf@plt+0&gt;:	jmpq   *0x2004c2(%rip)        # 0x600860 &lt;_GLOBAL_OFFSET_TABLE_+24&gt;
    0x000000000040039e &lt;printf@plt+6&gt;:	pushq  $0x0
    0x00000000004003a3 &lt;printf@plt+11&gt;:	jmpq   0x400388
    
    (gdb) disas printf
    Dump of assembler code for function printf:
    0x00000037aa44d360 &lt;printf+0&gt;:	sub    $0xd8,%rsp
    0x00000037aa44d367 &lt;printf+7&gt;:	mov    %rdx,0x30(%rsp)
    0x00000037aa44d36c &lt;printf+12&gt;:	movzbl %al,%edx
    0x00000037aa44d36f &lt;printf+15&gt;:	mov    %rsi,0x28(%rsp)
    0x00000037aa44d374 &lt;printf+20&gt;:	lea    0x0(,%rdx,4),%rax
    0x00000037aa44d37c &lt;printf+28&gt;:	lea    0x3f(%rip),%rdx        # 0x37aa44d3c2 &lt;printf+98&gt;

What does @plt mean here?

I want to change the *rpath* of an executable using `install_name_tool`, but I can&#39;t figure out what the *rpath* is right now. `install_name_tool` requires both the old and the new *rpath*&#39;s to be given on the commandline. What command can I use to print the *rpath* of an executable under macOS?

Print rpath of an executable on macOS

I read some articles discouraging of the use of DYLD_LIBRARY_PATH, as the the path of dynamic library should be fixed using -install_name, @rpath, and @loader_path. 

In terms of making a program that runs both on Linux and Mac OS X, DYLD_LIBRARY_PATH of Mac OS X does exactly what LD_LIBRARY_PATH of Linux. And, we can share (almost) the same make file that doesn&#39;t have the -install_name and @rpath. 

 * Is this OK to use DYLD_LIBRARY_PATH on Mac OS X?
 * What&#39;s the dynamic library search algorithm with Mac OS X when the binary can&#39;t find the dynamic library? current directory -&gt; DYLD_LIBRARY_PATH directories ... ? 

Is it OK to use DYLD_LIBRARY_PATH on Mac OS X? And, what&#39;s the dynamic library search algorithm with it?

I&#39;ve had numerous problems compiling shared objects that link statically against static libraries. This problem only shows up on x84_64 platforms. When doing the same compilation work on x86_32 I do not have any problems. 

Perhaps this is a OS specific GCC configuration thing, but my research indicates that its how GCC works on x86_64 platforms. Anyhow, I am using gcc 4.4.3 on Ubuntu 10.04 x86_64.

How is the problem fixed ?... Making sure all the static library dependencies are compiled with -fPIC.

**Question 1:** What is the difference between -fpic and -fPIC (apparently -fPIC generates more instructions on x86) ? Why is the later type more relevant in the x86_64 context ? 

**Question 2:** My assumption is that when you link against static code you are hard-wiring the functions into your binary at link time, why does it need the level of indirection the &quot;position independant code&quot; machinery provides ? 

**Question 3:** Now if x86 doesn&#39;t need -fpic / -fPIC to link shared objects against static archives why is it needed in x86_64 ? 

**Question 4:** even if it is needed why isn&#39;t it supplied implicitly ? I thought breaking changes was supposed to be a big no-no

Why does gcc not implicitly supply the -fPIC flag when compiling static libraries on x86_64

I have a shared library that is linked with another (third-party) shared library. My shared library is then loaded using dlopen in my application. All this works fine (assuming files are in the proper path etc).

Now, the problem is that I don&#39;t even need to specify to link against the third-party shared library when I link my library. GCC accept it without reporting errors about undefined references. So, the question; **how can I force GCC to notify me about undefined references**?

If I change my library to be (temporarily) an executable, I get undefined references (when not supplying the library to the linker). (Works fine if I specify it.)

I.e., the following is done:

    g++ -fPIC -shared -o libb.so b.o 
    g++ -fPIC -shared -o liba.so a.o
    g++ -o a.exe a.cpp 

Where the second line does NOT give out an error and the third line complains about an undefined reference.


Sample code:

a.h:

    class a
    {
    public:
        void foobar();
    };

a.cpp:

    #include &quot;a.h&quot;
    #include &quot;b.h&quot;
    
    void a::foobar()
    {
        b myB;
        myB.foobar();
    }

    int main()
    {
        a myA; myA.foobar();
    }

b.h:

    class b
    {
    public:
        void foobar();
    };

b.cpp:

    #include &quot;b.h&quot;
    
    void b::foobar()
    {
    }



Force GCC to notify about undefined references in shared libraries

**What I do**

When writing shared libraries for Linux, I tend to pay attention to relocations, symbol visibility, GOT/PLT etc.

When applicable, I am trying to avoid calling PLT stubs when functions from the same library call each other. For example, let&#39;s say a shared object provides two public functions - `foo()` and `bar()` (either of those can be called by user). The `bar()` function, however, also calls `foo()`. So what I do in this case is this:

 1. Define `_foo()` and `_bar()` functions that have private visibility.
 2. Define `foo()` and `bar()` weak aliases for `_foo()` and `_bar()` respectively.

That way, the code in shared object never uses weak symbols. It only invokes local functions, directly. For example, when `_bar()` is invoked, it calls `_foo()` directly.

But users are not aware of `_*` functions and always use corresponding weak aliases.

**How I do it**

In Linux, this is achieved by using the following construct:

    extern __typeof (_NAME) NAME __attribute__(weak, alias(&quot;_NAME&quot;));

**The problem**

Unfortunately, this does not work for OS X. I have no deep knowledge of OS X or its binary formats, so I poked around a bit and found a few examples of weak functions (like [this one][1]), but those don&#39;t quite do the same as you can have a weak symbol, but not a weak symbol that is an alias for DSO&#39;s local function.

**Possible solution...**

For now, I have just disabled this feature (that is implemented using macros) so that all symbols are global and have default visibility. The only way I can think of to achieve the same for now is to have all `_foo` functions with private visibility and have corresponding `foo` functions with default visibility and calling their &quot;hidden&quot; counterparts.

**A better way?**

That, however, requires a good chunk of code to be changed. Therefore I would prefer not to go there unless there is really no other way.

So what is the closes OS X alternative or the easiest way to get the same semantics/behavior?

  [1]: https://stackoverflow.com/questions/6009321/weak-symbol-link-on-mac-os-x

All Dynamic Linking Solutions on Gang of Coders

Total of 15 Dynamic Linking Solutions