3 ms·
On Linux with glibc, static linking breaks DNS resolver client: gethostbyname(3) and friends. As a workaround, you can link to musl libc, but that is only for s
by mkup 4y ago
On Linux with glibc, static linking breaks DNS resolver client: gethostbyname(3) and friends. As a workaround, you can link to musl libc, but that is only for software written in C, it does not work with C++. FreeBSD is better in this regard (their libc allows static linking without breaking DNS client, even for C++ software). However, on both OSes static linking is incompatible with dlopen(3) and dlsym(3), i.e. your application will be unable to load any .so files, so you if you link statically to libc then you must statically link to every other library. This is unlike Windows, where OS kernel API DLLs (ntdll.dll, kernel32.dll) are separated from libc DLL (msvcrt.dll if MSVC, cw3220.dll if Borland C++, mingw-something-something.dll if MinGW, IIRC there was something similar for Watcom etc), so libcs from different compilers may load simultaneously to the address space of a process (e.g. in application with third party plugins compiled against different libc, or a different version of the same vendor libc). Also on Windows OS kernel API DLLs (ntdll.dll, kernel32.dll) are always loaded to the address space of your process, even if you link to libc statically. So your application always can call LoadLibrary(), TlsAlloc() etc, and it is possible to write libc-less applications in the plain C.
- leni536 4y ago> As a workaround, you can link to musl libc, but that is only for software written in C, it does not work with C++. AFAIK you can link libc++ against musl.
- flohofwoe 4y ago> but that is only for software written in C, it does not work with C++. I have a pretty complex C++ command line tool which works just fine with MUSL and results in a distro-agnostic executable (https://github.com/floooh/sokol-tools https://github.com/floooh/sokol-tools). What potential problems should I be aware of?
- lloeki 4y agoEven in C there can be issues. the nokigiri ruby gem builds (or used to build) libxml and libxslt (which are pure C) with patches making effort in removing a couple of GNUisms. For C++ we were faced with some issues, so the process we ended up with is: - build musl, install it in some location - inject a few GCC libs and linux headers required for C runtime to have the above location be a proper sysroot for clang to use - build LLVM libc++ and a few libs (e.g libunwind) as static libs against that sysroot using clang, and inject them into the sysroot - build whatever C++ final product we want against the sysroot using clang, statically linking libc++ in - for a dynamic lib, remove " "needed" dynamic reference to libc.so in ELF. also, hide all symbols from libc++ and load with bind local so that when loaded the shared lib prefers its internal symbols (which would make it crash if it jumps to another libc++) and does not pollute the symbol namespace with its internal ones (which would make another lib crash if it jumps to the internal libc++) - for an executable binary instead of a lib, dynamic references may instead need to be altered so that it works for both It all hinges on musl being a subset of glibc, which is not entirely true either (see the musl website for differences in behaviour, which may or may not matter depending on the piece of software) See: https://wiki.musl-libc.org/functional-differences-from-glibc.html https://wiki.musl-libc.org/functional-differences-from-glibc... https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e92c6a891b3c99db018893/docker/libddwaf/README.md#portable-libddwaf-on-any-linux-26 https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e...
- intelVISA 4y agoglibc's hostility to static linkage (the whole NSS mess is farce) is why we moved to musl entirely, works with elegant C++ too!
- anthk 4y agoHow did Netscape and Mozilla (statically linked back in the day) load plugins then?
- delta64 4y agoWhy would static linking be incompatible with `dlopen`?