3 ms·

Because static linking has been out of vogue for so incredibly long in the C/C++ worlds, and above that, most languages either compile down to C, or are interpr

Because static linking has been out of vogue for so incredibly long in the C/C++ worlds, and above that, most languages either compile down to C, or are interpreted.

pjmlp 11y ago
Depends which C and C++ worlds you mean. In the GNU/Linux world maybe, but that is just one planet in the C and C++ galaxy.
- qwertyuiop924 11y ago
  I mean broadly almost all unixes, Mac, and Windows. All the big platforms. In embedded systems and plan9, static linking never left. But for mainstream development for desktop and server systems? Static linking has been out for a while.
  - vvanders 11y ago
    Gamedev is also very pro-static linking. *nix doesn't encompass all of C/C++.
    - qwertyuiop924 11y ago
      Huh. You learn something every day. But for the most part, everybody still links against libc dynamically. Solaris has actually stopped providing libc.a!
      - sveiss 11y ago
        Which makes sense when you think of libc as "the library which provides the system call interface to the OS, and just happens to provide a C runtime library as well". Making libc dynamic link only allows the OS developers to change the userland/kernel land interface as they see fit without breaking compatibility. The fact that this also ties you to a dynamically linked C runtime library is an artifact of the close ties between Unix and C. Over in Windows land, there isn't a tight coupling between libc and the system call interface. libc is provided by your compiler (Visual C++ provides static and dynamic versions), while the system call interface is provided by ntdll.dll and friends, which are part of the OS and free to change in future OS versions.
        qwertyuiop924 11y ago
        True enough, I suppose. It did break some stuff though. Go apparently encodes the syscall table. https://news.ycombinator.com/item?id=8817568 https://news.ycombinator.com/item?id=8817568
      - pjmlp 11y ago
        Yes, because the changes they did to the library aren't compatible with static linking. https://blogs.oracle.com/rie/entry/static_linking_where_did_it https://blogs.oracle.com/rie/entry/static_linking_where_did_... However, that is one implementation of one compiler in one specific OS.
        qwertyuiop924 11y ago
        True, but it shows the way the wind is blowing.
- deleted 11y ago
  [deleted]

Because static linking has been out of vogue for so incredibly long in the C/C++ worlds, and above that, most languages either compile down to C, or are interpreted.

pjmlp 11y ago

Depends which C and C++ worlds you mean. In the GNU/Linux world maybe, but that is just one planet in the C and C++ galaxy.

qwertyuiop924 11y ago
I mean broadly almost all unixes, Mac, and Windows. All the big platforms. In embedded systems and plan9, static linking never left. But for mainstream development for desktop and server systems? Static linking has been out for a while.
- vvanders 11y ago
  Gamedev is also very pro-static linking. *nix doesn't encompass all of C/C++.
  - qwertyuiop924 11y ago
    Huh. You learn something every day. But for the most part, everybody still links against libc dynamically. Solaris has actually stopped providing libc.a!
    - sveiss 11y ago
      Which makes sense when you think of libc as "the library which provides the system call interface to the OS, and just happens to provide a C runtime library as well". Making libc dynamic link only allows the OS developers to change the userland/kernel land interface as they see fit without breaking compatibility. The fact that this also ties you to a dynamically linked C runtime library is an artifact of the close ties between Unix and C. Over in Windows land, there isn't a tight coupling between libc and the system call interface. libc is provided by your compiler (Visual C++ provides static and dynamic versions), while the system call interface is provided by ntdll.dll and friends, which are part of the OS and free to change in future OS versions.
      - qwertyuiop924 11y ago
        True enough, I suppose. It did break some stuff though. Go apparently encodes the syscall table. https://news.ycombinator.com/item?id=8817568 https://news.ycombinator.com/item?id=8817568
    - pjmlp 11y ago
      Yes, because the changes they did to the library aren't compatible with static linking. https://blogs.oracle.com/rie/entry/static_linking_where_did_it https://blogs.oracle.com/rie/entry/static_linking_where_did_... However, that is one implementation of one compiler in one specific OS.
      - qwertyuiop924 11y ago
        True, but it shows the way the wind is blowing.
deleted 11y ago
[deleted]