Created attachment 9727 [details]
MUSL compatibility patch
libelf is incompatible with musl. Most of it is because error() is used and error.h is included in many places. If added to system.h, error.h could be removed from all subfiles without compilation error.
Other problems are the use of missing strndupa, canonicalize_file_name and a change the way strerror_r is used.
The patch attached allows elfutils to compile nicely using musl
Created attachment 9728 [details]
Minor sync fix
Created attachment 9731 [details]
MUSL compatibility patch
Could you split this into separate patches for each issue?
That makes it easier to review and easier to track down if there happens to be some issue later on.
- The idea of using system.h to define error () seems fine. But the current replacement doesn't seem complete. error () also flushes stdout first. Which we don't really seem to use, so might not be essential. But it also calls exit (status) if status != 0. Which is essential to how error is used in elfutils. Also error () updates error_message_count which is used in a couple of cases to know what exit code a program should use (if error itself didn't exit).
- I have to think about that strerror_r replacement. Normally we expect just a static string describing a known errno. But I see we have to handle unknown numbers too. hmmm.
- We only use strndupa in one place in the code in src/unstrip.c to create a directory. Could we just rewrite that?
- Since canonicalize_file_name (path) is defined as realpath(path, NULL) that change seems fine.
- error(): created a new bug 21008
- canonicalize_file_name(): create a new bug 21009
- strerror_r: create a new bug 21010
- strndupa is provided by MUSL if defined _GNU_SOURCE. Not a problem anymore
Until now, I still only tested compiling elfutils libraries.
It is not part of my use case but besides the problems already mentioned, elfutils/src will still miss from glibc:
- fts (I already use a patch to remove its dependency on lib*)
The approach used by voidlinux is to create independent libraries and checking for them on ./configure as in https://github.com/voidlinux/void-packages/blob/master/srcpkgs/elfutils/patches/musl-fts-obstack.patch
If I manually remove src from Makefile, everything else builds nicely.
(In reply to Luiz Angelo Daros de Luca from comment #5)
> It is not part of my use case but besides the problems already mentioned,
> elfutils/src will still miss from glibc:
> - obstack
> - fts (I already use a patch to remove its dependency on lib*)
We could probably add these using gnulib if it is useful for alternative glibc implementations that are missing them. But we haven't used gnulib modules before so we would need tweak the infrastructure a little to accommodate them.
I'm back with news.
I manage to compile all elfutils for OpenWrt, not just libs.
As expected, obstack and fts were missing. I managed to build using:
I created patches for elfutils allowing it to look for a libfts.so or libobstack.so. It builds but I feel I got too much/too little usage of both in linking.
At least for obstack, I need to merge some Makefile.am changes that got into another patch (https://github.com/luizluca/openwrt/blob/elfutils-full/package/libs/elfutils/patches/103-musl_elftools_full). I'll update soon.
As expected, the error_message_count used in some programs did break the build.
They are very few cases, most of them looks like could be replaced even with a local variable. Maybe it would be better to simply get rid of it.
Some missing macros: ACCESSPERMS, ALLPERMS, DEFFILEMODE.
qsort_r() is not provided in MUSL
Some elfutils programs (arlib, elfcmp, elfcompress, findtextrel, unstrip, ) do not include system.h. So, all ifdefs that solves some musl incompatibility where not present. I simply added them.
fnmatch() does not support FNM_EXTMATCH in musl (just 3 uses).
src/unstrip.c:void warn (const char *msg) might be using a too generic name. It collides with err.h warn. I simply renamed it.
(In reply to Luiz Angelo Daros de Luca from comment #7)
> I'm back with news.
> Almost there!
Thanks for the overview. If at all possible, could you open separate bugs for these issues? Then we can use this bug as tracker.