[Buildroot] [PATCH] package/elfutils: enable building with musl-based toolchains

[Arnout Vandecappelle]

On 17/07/2023 16:09, Ignacy Gawędzki wrote:
> On Fri, Jul 14, 2023 at 12:18:34PM +0200, thus spake Thomas Petazzoni:
>> Hello Ignacy,
>>
>> [...]
>>
>> And the fun game is that this work needs to be done recursively: once
>> you have checked if for example libbpf can now build with musl, you
>> need to look at the reverse dependencies of libbpf (in this case, only
>> package/kmemd).
>>
>> Could you have a look at doing this?
> 
> Sure.  I started having a look and stumbled upon an issue while
> test-pkg'ing libbpf.  Aside from many toolchains just being skipped
> (supposedly because of their lack of the minimum kernel headers
> version), it succeeded with those glibc and musl toolchains that it
> didn't skip, and failed with br-mips64-n64-full.  The latter is based
> on uClibc v1.0.36 and it turns out uClibc prior to v1.0.38 has no
> working definition of F_DUPFD_CLOEXEC, required by libbpf.
> 
> Now I have the following problem: how can I determine, from the
> Config.in's point-of-view, that the uClibc used by the toolchain is
> too old?  There are variable that are set when the toolchain is
> uclibc-based, but in this case I have
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM_UCLIBC=y and no way to know the actual
> version.  Forbidding libbpf as soon as
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM_UCLIBC=y seems overkill.

  Yeah, we have version checking for GCC and kernel headers, but not for libc. 
It's fairly rare that a version dependency is needed on libc. So we basically 
just assume that libc is up to date.

  What we sometimes do in such a case it to add an exception in the 
genrandconfig script, to make sure that that combination isn't tried.

  Ideally, though, that toolchain configuration should just be replaced with the 
equivalent bootlin toolchain. Only, there is no bootlin toolchain for 
mips64-n64. Any idea why not, Thomas?

  Regards,
  Arnout