package/elfutils: enable building with musl-based toolchains

Select BR2_PACKAGE_ARGP_STANDALONE as soon as the toolchain is not
glibc-based and add argp-standalone to build dependencies in that
case.

Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
---
 package/elfutils/Config.in   | 9 +++------
 package/elfutils/elfutils.mk | 5 ++++-
 2 files changed, 7 insertions(+), 7 deletions(-)

Hello Ignacy,

On Fri, 14 Jul 2023 11:08:04 +0200
Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr> wrote:

> Select BR2_PACKAGE_ARGP_STANDALONE as soon as the toolchain is not
> glibc-based and add argp-standalone to build dependencies in that
> case.
> 
> Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
> ---
>  package/elfutils/Config.in   | 9 +++------
>  package/elfutils/elfutils.mk | 5 ++++-
>  2 files changed, 7 insertions(+), 7 deletions(-)

This looks very good, and was tested successfully here, but you need to
go through all the reverse dependencies of elfutils, and check if they
can now build with musl. To do that:

$ git grep "select BR2_PACKAGE_ELFUTILS"
package/avrdude/Config.in:      select BR2_PACKAGE_ELFUTILS
package/bpftool/Config.in:      select BR2_PACKAGE_ELFUTILS
package/falcosecurity-libs/Config.in:   select BR2_PACKAGE_ELFUTILS
package/kexec-lite/Config.in:   select BR2_PACKAGE_ELFUTILS
package/libbpf/Config.in:       select BR2_PACKAGE_ELFUTILS
package/ltrace/Config.in:       select BR2_PACKAGE_ELFUTILS
package/makedumpfile/Config.in: select BR2_PACKAGE_ELFUTILS
package/mesa3d/Config.in:       select BR2_PACKAGE_ELFUTILS if BR2_PACKAGE_MESA3D_LLVM
package/mesa3d/Config.in:       select BR2_PACKAGE_ELFUTILS
package/petitboot/Config.in:    select BR2_PACKAGE_ELFUTILS
package/racehound/Config.in:    select BR2_PACKAGE_ELFUTILS

For example, avrdude has:

        depends on BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC # elfutils

which is no longer correct, as elfutils no longer has this dependency.
So you need to evaluate if each of those reverse dependencies now
builds fine with musl, in which case the uclibc || glibc dependency can
be dropped, or if the package still doesn't build with musl, in which
case it's no longer elfutils fault, but some other reason (and the
comment on the uclibc || glibc needs to be updated). As an example,
avrdude now builds fine with musl.

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?

Thanks a lot!

Thomas

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.

Ignacy

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

On Mon, 17 Jul 2023 17:31:19 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:

>   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?

Because I'm not super familiar with MIPS, so I don't know which
toolchain variants make the most sense, and I never got any request for
mips64-n64. I can probably add this toolchain variant in
toolchains.bootlin.com for the next rebuild.

Thomas

Hello Ignacy,

On Mon, 17 Jul 2023 16:09:32 +0200
Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr> wrote:

> 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.

Please note that this is a separate problem, unrelated to your effort
of making elfutils buildable with musl. Therefore, we will not require
you to fix all other unrelated problems. Of course, if you want to
tackle and solve those unrelated problems: great! But don't feel like
you have to: if they are unrelated, we are not going to make solving
them a requirement of merging your patches related to elfutils/musl.

> 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.

Arnout replied on that, and generally speaking we don't really care
anymore about "too old uClibc", I would probably not bother trying to
support all old uClibc toolchains.

Thomas