9 ms·

Rules of static linking: libstdc++, Libc, libgcc (2012)

51 points by optimalsolver 5y ago

michaelhoffman 5y ago
Would be nice if there were some explanation of why.
matheusmoreira 5y ago
> Google if you need an explanation for any of the above. Can anyone explain? Why can't libc and libgcc be statically linked? I'm not surprised, just curious.
- deleted 5y ago
  [deleted]
- jcelerier 5y ago
  they absolutely can. Glibc's NSS (https://venam.nixers.net/blog/unix/2020/11/01/resolving-a-hostname.html https://venam.nixers.net/blog/unix/2020/11/01/resolving-a-ho...) won't work and that's a good thing because putting domain name resolution in libc was a braindead idead from the very beginning. Domain name resolution behaviour should be program-controllable, not system-controllable (and thankfully we are starting to see a bit of sanity with web browsers which do bypass libc's domain name resolution) and especially not plug-in based which causes BS like things working differently whether avahi is installed or not. Note however that this will only work for simple non-gui apps. GUI apps generally need to load opengl drivers (which are shared objects) - thus you'd need to choose at link time which GL driver you want to use... which is not a practical thing to do.
  - rfoo 5y ago
    I'd argue that libgcc is safe to statically link though. The only downside of statically linking libgcc, as long as you keep your symbol visibility sane, i.e. not re-exporting everything which is unfortunately the default :(, is C++ exception across shared library boundary is not guaranteed to work. But if you are trying to make your library portable across different distro, having C++ thing in your external interface is never a good idea. Especially when you statically link libstdc++.
  - twic 5y ago
    > Domain name resolution behaviour should be program-controllable, not system-controllable This is pure insanity, of course, but i'm sure i'd be entertained by you trying to justify it, if you're inclined.
    - nybble41 5y ago
      Not the GP, but I would at least agree that the C library should not be handling domain name resolution or requiring any dynamically-loaded plugins. However, I am strongly opposed to having each application implement its own resolver and ignoring system settings. There should be a single system resolver where applications submit their requests. Something like the DBUS API presented by systemd-resolved, for example. Or the older NSCD protocol which permits out-of-process implementation of the NSS APIs, ostensibly for caching. systemd-resolved offers a nice compromise since, in addition to the rich DBUS API, it also acts as a recursive resolver on 127.0.0.53. So any applications that do implement their own resolution can be pointed there.
  - adev_ 5y ago
    > Domain name resolution behaviour should be program-controllable, not system-controllable I disagree, strongly. The last thing I want is to get every of my applications Avahi / Zeroconf aware for DNS or SSSD aware in enterprise environment for user authentication. Or worst, having to recompile them for that. System controllable for aspect like user authentication or service discovery makes perfect sense. What does not makes sense is to have it implemented as a glibc plugin system. This triggers a lot of problems for system that do not have the glibc (Golang / musl / statically linked binaries ) Ideally, that should be done through an IPC mechanism through to a local daemon to benefit of the best of both worlds.
- orra 5y ago
  Somebody else replied to you about the technical feasibility. It's also worth noting that if you statically link Glibc, you'll need to make more of an effort to comply with the LGPL. If you dynamically link, you automatically comply with 4(d).
aidanhs 5y ago
This is missing a lot of detail around libc (can't comment on the others), but was published ~1.5 years after musl was first released - I can imagine the subtleties being missed in a glibc monoculture. To expand a bit: 1. dlopen has interactions with static linking that you should understand if you use both at the same time. Different libcs expose different symbols for libc functions, so building your dynamic library against one libc may make it incompatible with another. And two libcs in the same program (one from the dylib, one from the binary) is a recipe for a very bad time - imagine freeing a pointer allocated with a different malloc implementation, or a different layout of libc structs 2. the complexity with glibc is it invokes dlopen as part of NSS, a feature that gets used as part of looking up users, among other things (it does this to allow integration with LDAP etc). You can actually see warnings at link time if you statically link glibc but pull in symbols that use NSS. You can disable NSS if you like at build time of glibc itself [0] (i.e. not your binary) 3. musl doesn't have the complexities of NSS and can be statically linked happily by default (I suspect that's probably what musl is most used for) [0] https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...
- my123 5y ago
  > 1. dlopen has interactions with static linking that you should understand if you use both at the same time. Using dlopen when static linking is used is deprecated in glibc.
- Joker_vD 5y ago
  > And two libcs in the same program (one from the dylib, one from the binary) is a recipe for a very bad time - imagine freeing a pointer allocated with a different malloc implementation, or a different layout of libc structs Depends on the exact architecture of the program, y'know. I remember a Windows app written in Delphi (so no libc whatever) that supported loading plugins written it whatever; and I've seen it load simultaneously plugins that linked against msvcrt90.dll and msvcrt100.dll with no problem. But that worked because plugins were required to export a FreeObject function that is supposed to be used to free whatever structures a plugin returned from its other functions. The main program tracked what piece of data came from where and called proper deallocation functions. But that requires acknowledgement of a fact that there is no "single, global C runtime".
tyingq 5y ago
How to deal with the DNS resolver is probably also worth throwing in as an issue. If you fully statically link a binary, and it needs to resolve an IP address, you can have issues. Because you're guessing what the local resolver setup might be. Do some google searches for "--enable-static-nss" to see some of the issues.
billconan 5y ago
I have a question, I'm creating a python binding (on linux). The company tool chain uses clang/llvm/libc++ , whereas python is built with gcc. what should I do? is it ok to statically link libc++ ?

51 points by optimalsolver 5y ago

Would be nice if there were some explanation of why.

> Google if you need an explanation for any of the above. Can anyone explain? Why can't libc and libgcc be statically linked? I'm not surprised, just curious.

deleted 5y ago
[deleted]
jcelerier 5y ago
they absolutely can. Glibc's NSS (https://venam.nixers.net/blog/unix/2020/11/01/resolving-a-hostname.html https://venam.nixers.net/blog/unix/2020/11/01/resolving-a-ho...) won't work and that's a good thing because putting domain name resolution in libc was a braindead idead from the very beginning. Domain name resolution behaviour should be program-controllable, not system-controllable (and thankfully we are starting to see a bit of sanity with web browsers which do bypass libc's domain name resolution) and especially not plug-in based which causes BS like things working differently whether avahi is installed or not. Note however that this will only work for simple non-gui apps. GUI apps generally need to load opengl drivers (which are shared objects) - thus you'd need to choose at link time which GL driver you want to use... which is not a practical thing to do.
- rfoo 5y ago
  I'd argue that libgcc is safe to statically link though. The only downside of statically linking libgcc, as long as you keep your symbol visibility sane, i.e. not re-exporting everything which is unfortunately the default :(, is C++ exception across shared library boundary is not guaranteed to work. But if you are trying to make your library portable across different distro, having C++ thing in your external interface is never a good idea. Especially when you statically link libstdc++.
- twic 5y ago
  > Domain name resolution behaviour should be program-controllable, not system-controllable This is pure insanity, of course, but i'm sure i'd be entertained by you trying to justify it, if you're inclined.
  - nybble41 5y ago
    Not the GP, but I would at least agree that the C library should not be handling domain name resolution or requiring any dynamically-loaded plugins. However, I am strongly opposed to having each application implement its own resolver and ignoring system settings. There should be a single system resolver where applications submit their requests. Something like the DBUS API presented by systemd-resolved, for example. Or the older NSCD protocol which permits out-of-process implementation of the NSS APIs, ostensibly for caching. systemd-resolved offers a nice compromise since, in addition to the rich DBUS API, it also acts as a recursive resolver on 127.0.0.53. So any applications that do implement their own resolution can be pointed there.
- adev_ 5y ago
  > Domain name resolution behaviour should be program-controllable, not system-controllable I disagree, strongly. The last thing I want is to get every of my applications Avahi / Zeroconf aware for DNS or SSSD aware in enterprise environment for user authentication. Or worst, having to recompile them for that. System controllable for aspect like user authentication or service discovery makes perfect sense. What does not makes sense is to have it implemented as a glibc plugin system. This triggers a lot of problems for system that do not have the glibc (Golang / musl / statically linked binaries ) Ideally, that should be done through an IPC mechanism through to a local daemon to benefit of the best of both worlds.
orra 5y ago
Somebody else replied to you about the technical feasibility. It's also worth noting that if you statically link Glibc, you'll need to make more of an effort to comply with the LGPL. If you dynamically link, you automatically comply with 4(d).

aidanhs 5y ago

This is missing a lot of detail around libc (can't comment on the others), but was published ~1.5 years after musl was first released - I can imagine the subtleties being missed in a glibc monoculture. To expand a bit: 1. dlopen has interactions with static linking that you should understand if you use both at the same time. Different libcs expose different symbols for libc functions, so building your dynamic library against one libc may make it incompatible with another. And two libcs in the same program (one from the dylib, one from the binary) is a recipe for a very bad time - imagine freeing a pointer allocated with a different malloc implementation, or a different layout of libc structs 2. the complexity with glibc is it invokes dlopen as part of NSS, a feature that gets used as part of looking up users, among other things (it does this to allow integration with LDAP etc). You can actually see warnings at link time if you statically link glibc but pull in symbols that use NSS. You can disable NSS if you like at build time of glibc itself [0] (i.e. not your binary) 3. musl doesn't have the complexities of NSS and can be statically linked happily by default (I suspect that's probably what musl is most used for) [0] https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...

my123 5y ago
> 1. dlopen has interactions with static linking that you should understand if you use both at the same time. Using dlopen when static linking is used is deprecated in glibc.
Joker_vD 5y ago
> And two libcs in the same program (one from the dylib, one from the binary) is a recipe for a very bad time - imagine freeing a pointer allocated with a different malloc implementation, or a different layout of libc structs Depends on the exact architecture of the program, y'know. I remember a Windows app written in Delphi (so no libc whatever) that supported loading plugins written it whatever; and I've seen it load simultaneously plugins that linked against msvcrt90.dll and msvcrt100.dll with no problem. But that worked because plugins were required to export a FreeObject function that is supposed to be used to free whatever structures a plugin returned from its other functions. The main program tracked what piece of data came from where and called proper deallocation functions. But that requires acknowledgement of a fact that there is no "single, global C runtime".

tyingq 5y ago

How to deal with the DNS resolver is probably also worth throwing in as an issue. If you fully statically link a binary, and it needs to resolve an IP address, you can have issues. Because you're guessing what the local resolver setup might be. Do some google searches for "--enable-static-nss" to see some of the issues.

billconan 5y ago

I have a question, I'm creating a python binding (on linux). The company tool chain uses clang/llvm/libc++ , whereas python is built with gcc. what should I do? is it ok to statically link libc++ ?