From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
Cc: Raul Cabello <raul.cabello@suse.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [RFC 1/2] toolchain: invert glibc <-> !static dependency
Date: Sat, 9 Oct 2021 22:27:44 +0200 [thread overview]
Message-ID: <20211009222744.365c0233@windsurf> (raw)
In-Reply-To: <20211006204133.465875-1-arnout@mind.be>
Hello,
On Wed, 6 Oct 2021 22:41:32 +0200
"Arnout Vandecappelle (Essensium/Mind)" <arnout@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@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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2021-10-09 20:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 20:41 [Buildroot] [RFC 1/2] toolchain: invert glibc <-> !static dependency Arnout Vandecappelle (Essensium/Mind)
2021-10-06 20:41 ` [Buildroot] [RFC 2/2] Config.in: move toolchain menu before build options Arnout Vandecappelle (Essensium/Mind)
2021-11-04 20:46 ` Yann E. MORIN
2021-11-08 18:17 ` Arnout Vandecappelle
2021-10-09 20:27 ` Thomas Petazzoni [this message]
2022-07-27 9:24 ` [Buildroot] [RFC 1/2] toolchain: invert glibc <-> !static dependency Thomas Petazzoni via buildroot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211009222744.365c0233@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=arnout@mind.be \
--cc=buildroot@buildroot.org \
--cc=raul.cabello@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox