[Buildroot] [RFC 1/2] toolchain: invert glibc <-> !static dependency

[Thomas Petazzoni]

Hello,

On Wed,  6 Oct 2021 22:41:32 +0200
"Arnout Vandecappelle (Essensium/Mind)" <arnout at mind.be> wrote:

> Currently, glibc depends on !BR2_STATIC_LIBS in all the toolchain
> variants.
> 
> However, for some architectures, glibc is the only supported libc.
> Therefore, for these, it's possible to select static libs, at which
> point no libc is selectable any more.
> 
> To overcome this situation, invert the dependency between glibc and
> static libs: BR2_STATIC_LIBS depends on !BR2_TOOLCHAIN_USES_GLIBC, and
> all the dependencies on !BR2_STATIC_LIBS are removed from the glibc
> variants of all toolchains.
> 
> Fixes: https://bugs.busybox.net/show_bug.cgi?id=14256
> 
> An alternative (simpler) fix would be to let BR2_STATIC_LIBS depend on
> !BR2_s390x. However, that doesn't solve the problem for the myriad of
> other architectures that only support glibc. In addition, there are some
> architecture variants that only support glibc, etc. etc., which really
> complicates stuff.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout at mind.be>

The reason why it was done this way is because the static/shared
decision appears in menuconfig before the toolchain selection. It would
be odd for a user to select "static libs" (which would be possible in
most configurations as we default to uClibc), then to select "glibc"
for the toolchain, do a build, and end up with a non static build.

Obviously, you can tell me that the user could also set glibc as a
toolchain, then go back to the build option, decide to do a static
build, and without notification the toolchain will be changed to uclibc.

So there's no ideal solution.

But then I see your PATCH 2/2, which indeed kind of "resolves" this
questioning.

The only alternative that I could think of is having a hidden boolean
BR2_ARCH_SUPPORTS_STATIC_LIBS, which would be selected by architectures
that support at least one C library that allows static linking. I don't
know if that's better, though.

What you did in this patch + inverting toolchain/build options in PATCH
2 is probably simpler/better.

I have not reviewed the patches carefully, but I'm fine with the
principle.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com