libddwaf
| libddwaf | gcc-static-linking | |
|---|---|---|
| 1 | 1 | |
| 34 | 0 | |
| - | - | |
| 8.6 | 2.0 | |
| 10 days ago | over 1 year ago | |
| C++ | C | |
| GNU General Public License v3.0 or later | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
libddwaf
-
Go 1.21 will (likely) have a static toolchain on Linux
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...
gcc-static-linking
-
Go 1.21 will (likely) have a static toolchain on Linux
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...
What are some alternatives?
sokol-tools - Command line tools for use with sokol headers
wazero - wazero: the zero dependency WebAssembly runtime for Go developers
evcxr
go - The Go programming language
purego