-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
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?
> 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