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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.