| Message ID | 20221026183427.3933387-1-thomas.petazzoni@bootlin.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/2] toolchain/toolchain-buildroot: introduce BR2_TOOLCHAIN_BUILDROOT_NONE | expand |
Thomas, All, On 2022-10-26 20:34 +0200, Thomas Petazzoni via buildroot spake thusly: > In the internal toolchain backend, we have a choice..endchoice block > to allow the user to select the C library, between glibc, uClibc and > musl. > > However, there are situations were no C library at all is > supported. In this case, the choice does not appear, and does not > allow to see the Config.in comments that are within the > choice..endchoice block and that may explain why no C library is > available. > > For example, on RISC-V 32-bit, the only C library supported is glibc, > and the minimum kernel header version required by glibc on this > architecture is 5.4.0. In a future commit, we are going to add this > dependency on glibc (to fix build issues on configurations that have > headers < 5.4.0). But since glibc is the only supported C library on > RISC-V 32-bit, it means that the choice..endchoice for the C library > contains no entry, preventing from seeing the Config.in comment. > > To address this issue, this commit adds a "dummy" > BR2_TOOLCHAIN_BUILDROOT_NONE option that shows up in the > choice..endchoice only when no C library is available. Thanks to this, > the choice..endchoice is never empty, and the Config.in comments can > be seen. > > If the user keeps BR2_TOOLCHAIN_BUILDROOT_NONE selected, then the > build will anyway abort early because package/Makefile.in has a check > to verify that a C library is selected, and aborts the build if not. > > Some could say that the problem should be resolved by instead > preventing the selection of headers < 5.4.0 on RISC-V 32-bit, but that > is difficult to do as the user can choose a custom header version, or > simply specific that (s)he wants to use the headers of the kernel > being built. In those situations, it's difficult to prevent selecting > headers < 5.4.0. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> As discussed on IRC, I added an exclusiong in genrandconfig. Applied to master, thanks. Regards, Yann E. MORIN. > --- > toolchain/toolchain-buildroot/Config.in | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in > index 6d55f87435..26d731d976 100644 > --- a/toolchain/toolchain-buildroot/Config.in > +++ b/toolchain/toolchain-buildroot/Config.in > @@ -80,6 +80,18 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL > > https://www.musl-libc.org/ > > +config BR2_TOOLCHAIN_BUILDROOT_NONE > + bool "none" > + depends on !BR2_PACKAGE_UCLIBC_SUPPORTS && \ > + !BR2_PACKAGE_GLIBC_SUPPORTS && \ > + !BR2_PACKAGE_MUSL_SUPPORTS > + help > + This option is visible if no C library is available for the > + currently selected configuration. If you select this option, > + the build will refuse to start as Buildroot needs a C > + library to build a toolchain. Change your configuration > + settings to make sure one of the C libraries is selected. > + > endchoice > > config BR2_TOOLCHAIN_BUILDROOT_LIBC > -- > 2.37.3 > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
>>>>> "Thomas" == Thomas Petazzoni via buildroot <buildroot@buildroot.org> writes: > In the internal toolchain backend, we have a choice..endchoice block > to allow the user to select the C library, between glibc, uClibc and > musl. > However, there are situations were no C library at all is > supported. In this case, the choice does not appear, and does not > allow to see the Config.in comments that are within the > choice..endchoice block and that may explain why no C library is > available. > For example, on RISC-V 32-bit, the only C library supported is glibc, > and the minimum kernel header version required by glibc on this > architecture is 5.4.0. In a future commit, we are going to add this > dependency on glibc (to fix build issues on configurations that have > headers < 5.4.0). But since glibc is the only supported C library on > RISC-V 32-bit, it means that the choice..endchoice for the C library > contains no entry, preventing from seeing the Config.in comment. > To address this issue, this commit adds a "dummy" > BR2_TOOLCHAIN_BUILDROOT_NONE option that shows up in the > choice..endchoice only when no C library is available. Thanks to this, > the choice..endchoice is never empty, and the Config.in comments can > be seen. > If the user keeps BR2_TOOLCHAIN_BUILDROOT_NONE selected, then the > build will anyway abort early because package/Makefile.in has a check > to verify that a C library is selected, and aborts the build if not. > Some could say that the problem should be resolved by instead > preventing the selection of headers < 5.4.0 on RISC-V 32-bit, but that > is difficult to do as the user can choose a custom header version, or > simply specific that (s)he wants to use the headers of the kernel > being built. In those situations, it's difficult to prevent selecting > headers < 5.4.0. > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Committed to 2022.08.x, thanks. 2022.02.x does have the BR2_PACKAGE_<foo>_SUPPORTS, so I didn't add it there.
diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in index 6d55f87435..26d731d976 100644 --- a/toolchain/toolchain-buildroot/Config.in +++ b/toolchain/toolchain-buildroot/Config.in @@ -80,6 +80,18 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL https://www.musl-libc.org/ +config BR2_TOOLCHAIN_BUILDROOT_NONE + bool "none" + depends on !BR2_PACKAGE_UCLIBC_SUPPORTS && \ + !BR2_PACKAGE_GLIBC_SUPPORTS && \ + !BR2_PACKAGE_MUSL_SUPPORTS + help + This option is visible if no C library is available for the + currently selected configuration. If you select this option, + the build will refuse to start as Buildroot needs a C + library to build a toolchain. Change your configuration + settings to make sure one of the C libraries is selected. + endchoice config BR2_TOOLCHAIN_BUILDROOT_LIBC
In the internal toolchain backend, we have a choice..endchoice block to allow the user to select the C library, between glibc, uClibc and musl. However, there are situations were no C library at all is supported. In this case, the choice does not appear, and does not allow to see the Config.in comments that are within the choice..endchoice block and that may explain why no C library is available. For example, on RISC-V 32-bit, the only C library supported is glibc, and the minimum kernel header version required by glibc on this architecture is 5.4.0. In a future commit, we are going to add this dependency on glibc (to fix build issues on configurations that have headers < 5.4.0). But since glibc is the only supported C library on RISC-V 32-bit, it means that the choice..endchoice for the C library contains no entry, preventing from seeing the Config.in comment. To address this issue, this commit adds a "dummy" BR2_TOOLCHAIN_BUILDROOT_NONE option that shows up in the choice..endchoice only when no C library is available. Thanks to this, the choice..endchoice is never empty, and the Config.in comments can be seen. If the user keeps BR2_TOOLCHAIN_BUILDROOT_NONE selected, then the build will anyway abort early because package/Makefile.in has a check to verify that a C library is selected, and aborts the build if not. Some could say that the problem should be resolved by instead preventing the selection of headers < 5.4.0 on RISC-V 32-bit, but that is difficult to do as the user can choose a custom header version, or simply specific that (s)he wants to use the headers of the kernel being built. In those situations, it's difficult to prevent selecting headers < 5.4.0. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> --- toolchain/toolchain-buildroot/Config.in | 12 ++++++++++++ 1 file changed, 12 insertions(+)