4 ms·

> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions and amazingly it's worse than MS DLL hell of MSVC redistributable shambles. O

> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions and amazingly it's worse than MS DLL hell of MSVC redistributable shambles. One option is to statically link against musl libc [1]. The kernel ABI is about the only stable thing you can rely on (which is something you _can't_ rely on for macOS or Windows). [1] https://www.musl-libc.org/ https://www.musl-libc.org/

dazzawazza 8y ago
Thank you. musl looks very interesting. It's something I didn't consider, I'll add it to my research list :)
scns 8y ago
Is it not possible to link glibc staticalliy? IIRC musl has readability and code size in mind while glibc optimizes for performance at the cost of readability and codesize.
- nineteen999 8y ago
  The problem that I know of is that glibc supports loading DSO modules, eg. for NSS, so it's not going to support pluggable NSS sources like LDAP etc when statically linked. There are workarounds, however: https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead https://stackoverflow.com/questions/3430400/linux-static-lin... Can't imagine many Linux gamers are going to need NSS support in their game binaries. It's a bit of a stretch to say glibc doesn't support static linking, perhaps "officially" it doesn't, its just not all the extended features are going to work. Static linking is generally going to be frowned upon these days however since you're effectively linking security issues into the binary forever.
- rurban 8y ago
  Not really. musl optimizes for performance and codesize, whilst glibc optimizes for the random user who needs to read error message in farsi and logs on via an external LDAP service, and needs LD and MALLOC hooks to debug weird edge cases. glibc unicode tables are huge, musl are tiny. glibc uses assembler optimizations for everything, whilst musl uses compiler auto-vectorization, which mostly beats handwritten assembly, esp. with constant arguments.
AnIdiotOnTheNet 8y ago
> The kernel ABI is about the only stable thing you can rely on (which is something you _can't_ rely on for macOS or Windows). In Windows's case, technically accurate but not really relevant, since the interface for working with the base DLLs like kernel32, user32, etc. hasn't changed.
- wtetzner 8y ago
  Sorry I wasn't clearer. I just meant that on Windows and macOS, you can rely on certain userland libraries, but not the kernel ABI, while on Linux you can rely on the kernel ABI, but not the libraries.
Procedural 8y ago
Note a program compiled with musl can't use shared libraries which were compiled with glibc. I wrote my own tiny x64 C standard library which, unlike musl, is compatible with other glibc libraries: https://github.com/procedural/c_stdlib https://github.com/procedural/c_stdlib
- deleted 8y ago
  [deleted]

dazzawazza 8y ago

Thank you. musl looks very interesting. It's something I didn't consider, I'll add it to my research list :)

scns 8y ago

Is it not possible to link glibc staticalliy? IIRC musl has readability and code size in mind while glibc optimizes for performance at the cost of readability and codesize.

nineteen999 8y ago
The problem that I know of is that glibc supports loading DSO modules, eg. for NSS, so it's not going to support pluggable NSS sources like LDAP etc when statically linked. There are workarounds, however: https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead https://stackoverflow.com/questions/3430400/linux-static-lin... Can't imagine many Linux gamers are going to need NSS support in their game binaries. It's a bit of a stretch to say glibc doesn't support static linking, perhaps "officially" it doesn't, its just not all the extended features are going to work. Static linking is generally going to be frowned upon these days however since you're effectively linking security issues into the binary forever.
rurban 8y ago
Not really. musl optimizes for performance and codesize, whilst glibc optimizes for the random user who needs to read error message in farsi and logs on via an external LDAP service, and needs LD and MALLOC hooks to debug weird edge cases. glibc unicode tables are huge, musl are tiny. glibc uses assembler optimizations for everything, whilst musl uses compiler auto-vectorization, which mostly beats handwritten assembly, esp. with constant arguments.

AnIdiotOnTheNet 8y ago

> The kernel ABI is about the only stable thing you can rely on (which is something you _can't_ rely on for macOS or Windows). In Windows's case, technically accurate but not really relevant, since the interface for working with the base DLLs like kernel32, user32, etc. hasn't changed.

wtetzner 8y ago
Sorry I wasn't clearer. I just meant that on Windows and macOS, you can rely on certain userland libraries, but not the kernel ABI, while on Linux you can rely on the kernel ABI, but not the libraries.

Procedural 8y ago

Note a program compiled with musl can't use shared libraries which were compiled with glibc. I wrote my own tiny x64 C standard library which, unlike musl, is compatible with other glibc libraries: https://github.com/procedural/c_stdlib https://github.com/procedural/c_stdlib

deleted 8y ago
[deleted]