Hi Calvin, On Tue, 2026-10-13 at 12:48 -0300, Calvin Buckley wrote: > I've had a need for a modern libelf (though it would be convenient to > have i.e. eu-readelf) on macOS. Unfortunately, elfutils does assume a > GNU/Linux environment, with ELF binaries (on the host side), using > glibc extensions, and the GNU linker.
Yes, most of those assumptions are there. But it should now also compile with clang/llvm and work against alternative libc implementations like musl (assuming some alternatives libraries for argp, fts, obstack are there). The core assumption that the platform is ELF based is somewhat core though. > I have a (mostly ugly) incomplete work-in-progress patch set (which does > not yet fully build) if people are interested. The pieces of it consist > mostly of: > > - Lots of assumption of GNU linker flags and behaviours > I haven't got all of these. Some of these are needed for i.e. symbol > versioning, which I think isn't really possible in the Mach-O world. > I think libtool might handle a lot of these cases, since elfutils > already uses autotools; it would probably make sense to adopt it. > > - Mach-O not having strong aliases > Some of this can be done via making wrapper functions or using weak > aliases instead, but this might not be ideal. > > - Using byteswap/endian.h > For these, I've reimplemented them in terms of the GCC (which clang > also has) builtins for bswap when these are missing, and wrapping > the Apple equivalents of i.e. le32toh with #define. > > - Missing functionality like obstack, tdestroy, memrchr, > posix_fallocate, __fsetlocking, program_invocation_short_name etc. > Some of these can be handled by i.e. the musl-obstack shim, libiberty, > etc. or shimming/ignoring them - but I think the GNU-native answer > would be slathering a thick layer of gnulib to handle these. > > If you're interested, I could post the parts I think are more > upstreamable, even if it's not a complete patch set. Please do post these and we'll look at what seems reasonable. Thanks, Mark
