3 ms·
> You are expected to bring your own, and doing so means your process has multiple libc's loaded into its address space. That only massively compounds the prob
by matheusmoreira 2mo ago
> You are expected to bring your own, and doing so means your process has multiple libc's loaded into its address space.
That only massively compounds the problem.
> And if you choose to build a binary that doesn't need a libc, you won't be bringing one.
NT system calls are not stable. You still need to link against ntdll.dll at the very least, like a forced Linux vDSO.
- dwattttt 2mo ago> That only massively compounds the problem. The Windows ecosystem, that manages to deliver built binaries easily & widely, regardless of whether the author has a 1 year old OS or a 15 year old OS, suggests that it's not as big a problem as you believe.
- matheusmoreira 2mo agoIt's not a problem in the same way that things like snap or flatpak aren't problems. It works but it bloats things up considerably and makes you wonder where it all went so wrong. I mean, dozens of slightly incompatible runtimes inside a single process?
- dwattttt 2mo agoThose incompatible runtimes are separated by a linker that doesn't resolve all symbols globally, but rather scoped to the shared object they're expected from. They all coexist happily, and if you're so inclined you could resolve the same symbol from each, if you had reason to do so.