Marc Poulhiès <poulh...@adacore.com> writes: >>> Would it make sense to drop the "Glibc" here? Having "Glibc" means that >>> we end up with glibc specifics in files that are not glibc specific (e.g. >>> a-exetim__posix.adb or s-osinte__linux.ads). Are these particular macros >>> glibc specific? We need these to build with other libc (e.g. musl). >> >> As an aside: I won't promise to work on this just yet, but there's some >> fixes needed >> to get GNAT building on musl. If these are welcomed, I'll move it a bit >> higher up on my list. > > Unless the changes are very intrusive, I don't expect any pushback :) >
Excellent! Should be nothing of that sort. > As I just remembered about some Alpine local patch to get gnat to build, > I tried to find it again, and found a change related to 64 bits time: > > https://gitlab.kveer.fr/upstream/alpine-aports/-/blob/3.21-stable/main/gcc/0032-libgnat-time_t-is-always-64-bit-on-musl-libc.patch > > So it's possible this change makes the musl build a bit easier. > > But there are some more: > https://gitlab.kveer.fr/upstream/alpine-aports/-/blob/3.21-stable/main/gcc/0025-ada-libgnarl-compatibility-for-musl.patch > > I guess you are referring to similar changes? > Yes, and I think https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/0026-ada-musl-support-fixes.patch is the biggest one. The main challenge with these patches is often they've been carried around for years and all rationale/commentary is lost, and sadly assume musl-only, which is why I usually write them from scratch and just compare my final result with the ones in other musl distros to see if I missed anything (or not). cheers, sam
