Support dynamically-linked FreeBSD libc when cross-compiling #23835
Conversation
alexrp
force-pushed
the
freebsd-libc
branch
4 times, most recently
from
dac1fca to
40dfc11
Compare
|
What is the delta installation size (both compressed and on disk)? |
|
Uncompressed Speaking of size savings: #21258 |
|
hmmmm, +13% / +24% is pretty bad for only gaining 1 new target. 14 megabytes of headers seems excessive. The files added look reasonable though. |
|
I think it looks worse than it actually is because we tend to take for granted the Linux situation of kernel and libc headers being separate. Some perspective:
In that light, I don't think it looks that bad actually. That said, there's definitely room to prune FreeBSD headers; some are really kernel-only, and there are probably still some that aren't strictly related to the kernel or libc. But pruning these is going to be a very manual and tedious process.
Also, just to be clear, this is adding all FreeBSD 14 targets:
|
|
zig-bootstrap works: @mikdusan also verified that the resulting binary actually runs on FreeBSD 14. This should be ready for review. |
alexrp
force-pushed
the
freebsd-libc
branch
3 times, most recently
from
6edf506 to
12465d3
Compare
osreldate.h and sys/param.h were manually adjusted to not __FreeBSD_version since it will be defined by the compiler.
* NT_FREEBSD_ABI_TAG was manually adjusted from using a hardcoded value to using __FreeBSD_version which will be defined by the compiler. * GCJ stuff was removed. * HAVE_CTORS definitions were removed.
Currently covers version 1.7 (FreeBSD 14.0.0).
Based on data in std.zig.target.
…raries. Only works for FreeBSD 14+. Note that we still default to targeting FreeBSD 13. Contributes to ziglang#2876.
The driver doesn't support it, and FreeBSD 13+ on PPC64 uses ELFv2 anyway.
I agree, thanks for sharing this additional insight! |
…ibc.so. These symbols are defined in the statically-linked startup code. The real libc.so.7 contains strong references to them, so they need to be put into the dynamic symbol table.
We don't yet have a direct syscall layer in std.os.freebsd.
FWIW so did FreeBSD: freebsd/freebsd-src@a60615d
I wonder if there's anything we can do in FreeBSD to make this less of a tedious, manual process. |
Great!
Well, the tedious work is unavoidable; it's just a question of where it happens and who does it. 🙂 If you take a peek at our libc update instructions, you can see that we run a variation of this per-target: MAKEOBJDIRPREFIX=$PWD/build tools/build/make.py installworld --bootstrap-toolchain -j$(nproc) TARGET=amd64 TARGET_ARCH=amd64 SRCCONF=$PWD/src.conf NO_SHARE=1 NO_LIBS=1 SUBDIR_OVERRIDE="include lib/libc lib/libdl lib/libelf lib/libexecinfo lib/librt lib/libthr lib/libstdthreads lib/libutil lib/msun libexec/rtld-elf" NO_ROOT=1 DESTDIR=$PWD/sysroot/amd64Best as I can tell, the majority (if not all) of the "unwanted" headers come from the Perhaps one solution here would be to move the installation logic for kernel-only headers into the There are also some (I think...?) library headers that we manually remove: rm -rf sysroot/*/usr/include/bsm
rm -rf sysroot/*/usr/include/gssapi
rm -rf sysroot/*/usr/include/tekenIt seems a bit odd that these are installed from |
libc update instructions: https://github.com/ziglang/zig/wiki/Updating-libc#freebsd
ABI tooling: https://github.com/ziglang/libc-abi-tools/tree/main/freebsd
Caveats:
abilistsfile, not minor/patch..init/.finibecause it's 2025 and people should be using.init_array/.fini_array.Contributes to #2876.
My next priority will be dynamically-linked libc for NetBSD (#2877), after which I'll look at static linking for both.
Release Notes
Zig now allows cross-compiling to FreeBSD 14+ by providing stub libraries for dynamic libc, similar to how cross-compilation for glibc is handled. Additionally, all system and libc headers are provided.