-
That's nice for Alpine isn't it? That uses MUSL.
Speaking of portability and golang, this sounds promising: https://github.com/tetratelabs/wazero Can anyone tell me if this is close to working as well as wasmtime?
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
> 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 (https://github.com/floooh/sokol-tools). What potential problems should I be aware of?
-
I didn't believe you that it's broken, but you're right - very disappointing. For anyone interested, the bug for it being is at [1] (reported mid 2021).
The build failure is easy to fix, so I created a repo at [2] which builds a program against a glibc with static nss. I verified with strace that it does indeed check nsswitch.conf and try and load dynamic libraries (I'd at least submit my patch [3] for the build failure but I find mailing lists to be a hassle)
All this said, I wouldn't call it undocumented - it's documented in the `configure --help` itself as well as the online version [4], and it has an FAQ entry [5].
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=27959
[2] https://github.com/aidanhs/gcc-static-linking
[3] https://github.com/aidanhs/gcc-static-linking/blob/39ff3b754...
[4] https://www.gnu.org/software/libc/manual/html_node/Configuri...
[5] https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...
-
Even in C there can be issues. the nokigiri ruby gem builds (or used to build) libxml and libxslt (which are pure C) and has to make effort remove 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 dynamic reference to some shared libs (can't recall if it's libc.so or ld.so). 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 reference would 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)
https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e...
-
It doesn't matter. What does is Go 1.0 shipped without generics. That single decision immutably affected the entire language. Now that generics have been retrofitted, the issues are clear as day:
- Awkward transition period between a stdlib with and without generics: [1]
- Completely different APIs for built-in data structures (slices, maps) and generic ones
- Lack of obvious follow-up features that would have been there at 1.0 if generics were added, e.g. iterators
[1]: https://github.com/golang/go/discussions/48287
