diff mbox series

[next] toolchain/toolchain-buildroot: default to glibc as the C library

Message ID 20220815202955.2216503-1-thomas.petazzoni@bootlin.com
State Accepted
Headers show
Series [next] toolchain/toolchain-buildroot: default to glibc as the C library | expand

Commit Message

Thomas Petazzoni Aug. 15, 2022, 8:29 p.m. UTC
This is perhaps the most controversial change for Buildroot that can
be written in a two-liner.

Historically, we have used uClibc as our default C library, as
Buildroot was created initially as a test-bed for uClibc, and also
because uClibc made a lot of sense for embedded Linux systems, due to
its smaller size and fine-grained configurability.

Since then, the landscape of embedded Linux systems has changed. Even
though Buildroot happily supports really low-end devices, the vast
majority of Buildroot users are quite certainly running the resulting
system on a reasonably powerful platform, with significant amount of
RAM and storage. In this context, the benefits of uClibc are no longer
that much relevant, and glibc causes less "troubles". Therefore, this
patch proposes to use glibc as our default C library when using the
internal toolchain backend instead of uClibc.

Of course, we will keep the support for uClibc, which remains an
important C library choice, for space-constrained systems, or simply
for architectures that are not supported by glibc.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 toolchain/toolchain-buildroot/Config.in | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Comments

Arnout Vandecappelle Aug. 16, 2022, 8:50 p.m. UTC | #1
On 15/08/2022 22:29, Thomas Petazzoni wrote:
> This is perhaps the most controversial change for Buildroot that can
> be written in a two-liner.
> 
> Historically, we have used uClibc as our default C library, as
> Buildroot was created initially as a test-bed for uClibc, and also
> because uClibc made a lot of sense for embedded Linux systems, due to
> its smaller size and fine-grained configurability.
> 
> Since then, the landscape of embedded Linux systems has changed. Even
> though Buildroot happily supports really low-end devices, the vast
> majority of Buildroot users are quite certainly running the resulting
> system on a reasonably powerful platform, with significant amount of
> RAM and storage. In this context, the benefits of uClibc are no longer
> that much relevant, and glibc causes less "troubles". Therefore, this
> patch proposes to use glibc as our default C library when using the
> internal toolchain backend instead of uClibc.
> 
> Of course, we will keep the support for uClibc, which remains an
> important C library choice, for space-constrained systems, or simply
> for architectures that are not supported by glibc.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

  Regards,
  Arnout

> ---
>   toolchain/toolchain-buildroot/Config.in | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
> index 836af3b22a..9956dc4383 100644
> --- a/toolchain/toolchain-buildroot/Config.in
> +++ b/toolchain/toolchain-buildroot/Config.in
> @@ -22,8 +22,7 @@ config BR2_TOOLCHAIN_BUILDROOT_VENDOR
>   
>   choice
>   	prompt "C library"
> -	default BR2_TOOLCHAIN_BUILDROOT_UCLIBC
> -	default BR2_TOOLCHAIN_BUILDROOT_GLIBC if BR2_powerpc64
> +	default BR2_TOOLCHAIN_BUILDROOT_GLIBC
>   
>   config BR2_TOOLCHAIN_BUILDROOT_UCLIBC
>   	bool "uClibc-ng"
Yann E. MORIN Aug. 16, 2022, 9:03 p.m. UTC | #2
Thomas, All,

On 2022-08-15 22:29 +0200, Thomas Petazzoni via buildroot spake thusly:
> This is perhaps the most controversial change for Buildroot that can
> be written in a two-liner.
> 
> Historically, we have used uClibc as our default C library, as
> Buildroot was created initially as a test-bed for uClibc, and also
> because uClibc made a lot of sense for embedded Linux systems, due to
> its smaller size and fine-grained configurability.
> 
> Since then, the landscape of embedded Linux systems has changed. Even
> though Buildroot happily supports really low-end devices, the vast
> majority of Buildroot users are quite certainly running the resulting
> system on a reasonably powerful platform, with significant amount of
> RAM and storage. In this context, the benefits of uClibc are no longer
> that much relevant, and glibc causes less "troubles". Therefore, this
> patch proposes to use glibc as our default C library when using the
> internal toolchain backend instead of uClibc.
> 
> Of course, we will keep the support for uClibc, which remains an
> important C library choice, for space-constrained systems, or simply
> for architectures that are not supported by glibc.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>

Yes, I will be a bit sad that we demote uClibc-ng, but let's face it:
the word moves on, let's move along.

Regards,
Yann E. MORIN.

> ---
>  toolchain/toolchain-buildroot/Config.in | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
> index 836af3b22a..9956dc4383 100644
> --- a/toolchain/toolchain-buildroot/Config.in
> +++ b/toolchain/toolchain-buildroot/Config.in
> @@ -22,8 +22,7 @@ config BR2_TOOLCHAIN_BUILDROOT_VENDOR
>  
>  choice
>  	prompt "C library"
> -	default BR2_TOOLCHAIN_BUILDROOT_UCLIBC
> -	default BR2_TOOLCHAIN_BUILDROOT_GLIBC if BR2_powerpc64
> +	default BR2_TOOLCHAIN_BUILDROOT_GLIBC
>  
>  config BR2_TOOLCHAIN_BUILDROOT_UCLIBC
>  	bool "uClibc-ng"
> -- 
> 2.37.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
Peter Korsgaard Aug. 16, 2022, 9:37 p.m. UTC | #3
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Thomas, All,
 > On 2022-08-15 22:29 +0200, Thomas Petazzoni via buildroot spake thusly:
 >> This is perhaps the most controversial change for Buildroot that can
 >> be written in a two-liner.
 >> 
 >> Historically, we have used uClibc as our default C library, as
 >> Buildroot was created initially as a test-bed for uClibc, and also
 >> because uClibc made a lot of sense for embedded Linux systems, due to
 >> its smaller size and fine-grained configurability.
 >> 
 >> Since then, the landscape of embedded Linux systems has changed. Even
 >> though Buildroot happily supports really low-end devices, the vast
 >> majority of Buildroot users are quite certainly running the resulting
 >> system on a reasonably powerful platform, with significant amount of
 >> RAM and storage. In this context, the benefits of uClibc are no longer
 >> that much relevant, and glibc causes less "troubles". Therefore, this
 >> patch proposes to use glibc as our default C library when using the
 >> internal toolchain backend instead of uClibc.
 >> 
 >> Of course, we will keep the support for uClibc, which remains an
 >> important C library choice, for space-constrained systems, or simply
 >> for architectures that are not supported by glibc.
 >> 
 >> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

 > Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>

 > Yes, I will be a bit sad that we demote uClibc-ng, but let's face it:
 > the word moves on, let's move along.

Agreed.

Acked-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN Aug. 17, 2022, 6:46 p.m. UTC | #4
Thomas, All,

On 2022-08-15 22:29 +0200, Thomas Petazzoni spake thusly:
> This is perhaps the most controversial change for Buildroot that can
> be written in a two-liner.
> 
> Historically, we have used uClibc as our default C library, as
> Buildroot was created initially as a test-bed for uClibc, and also
> because uClibc made a lot of sense for embedded Linux systems, due to
> its smaller size and fine-grained configurability.
> 
> Since then, the landscape of embedded Linux systems has changed. Even
> though Buildroot happily supports really low-end devices, the vast
> majority of Buildroot users are quite certainly running the resulting
> system on a reasonably powerful platform, with significant amount of
> RAM and storage. In this context, the benefits of uClibc are no longer
> that much relevant, and glibc causes less "troubles". Therefore, this
> patch proposes to use glibc as our default C library when using the
> internal toolchain backend instead of uClibc.
> 
> Of course, we will keep the support for uClibc, which remains an
> important C library choice, for space-constrained systems, or simply
> for architectures that are not supported by glibc.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Applied to next, thanks.

Regards,
Yann E. MORIN.

> ---
>  toolchain/toolchain-buildroot/Config.in | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
> index 836af3b22a..9956dc4383 100644
> --- a/toolchain/toolchain-buildroot/Config.in
> +++ b/toolchain/toolchain-buildroot/Config.in
> @@ -22,8 +22,7 @@ config BR2_TOOLCHAIN_BUILDROOT_VENDOR
>  
>  choice
>  	prompt "C library"
> -	default BR2_TOOLCHAIN_BUILDROOT_UCLIBC
> -	default BR2_TOOLCHAIN_BUILDROOT_GLIBC if BR2_powerpc64
> +	default BR2_TOOLCHAIN_BUILDROOT_GLIBC
>  
>  config BR2_TOOLCHAIN_BUILDROOT_UCLIBC
>  	bool "uClibc-ng"
> -- 
> 2.37.2
>
Romain Naour Aug. 17, 2022, 7:35 p.m. UTC | #5
Hello,

Le 16/08/2022 à 23:37, Peter Korsgaard a écrit :
>>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> 
>  > Thomas, All,
>  > On 2022-08-15 22:29 +0200, Thomas Petazzoni via buildroot spake thusly:
>  >> This is perhaps the most controversial change for Buildroot that can
>  >> be written in a two-liner.
>  >> 
>  >> Historically, we have used uClibc as our default C library, as
>  >> Buildroot was created initially as a test-bed for uClibc, and also
>  >> because uClibc made a lot of sense for embedded Linux systems, due to
>  >> its smaller size and fine-grained configurability.
>  >> 
>  >> Since then, the landscape of embedded Linux systems has changed. Even
>  >> though Buildroot happily supports really low-end devices, the vast
>  >> majority of Buildroot users are quite certainly running the resulting
>  >> system on a reasonably powerful platform, with significant amount of
>  >> RAM and storage. In this context, the benefits of uClibc are no longer
>  >> that much relevant, and glibc causes less "troubles". Therefore, this
>  >> patch proposes to use glibc as our default C library when using the
>  >> internal toolchain backend instead of uClibc.
>  >> 
>  >> Of course, we will keep the support for uClibc, which remains an
>  >> important C library choice, for space-constrained systems, or simply
>  >> for architectures that are not supported by glibc.
>  >> 
>  >> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> 
>  > Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
> 
>  > Yes, I will be a bit sad that we demote uClibc-ng, but let's face it:
>  > the word moves on, let's move along.
> 
> Agreed.
> 
> Acked-by: Peter Korsgaard <peter@korsgaard.com>
> 
The next move is probably increase testing with glibc in the Buildroot testsuite?

Acked-by: Romain Naour <romain.naour@gmail.com>

Best regards,
Romain
Arnout Vandecappelle Aug. 18, 2022, 8:15 p.m. UTC | #6
On 17/08/2022 21:35, Romain Naour wrote:
> Hello,
> 
> Le 16/08/2022 à 23:37, Peter Korsgaard a écrit :
>>>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>>
>>   > Thomas, All,
>>   > On 2022-08-15 22:29 +0200, Thomas Petazzoni via buildroot spake thusly:
>>   >> This is perhaps the most controversial change for Buildroot that can
>>   >> be written in a two-liner.
>>   >>
>>   >> Historically, we have used uClibc as our default C library, as
>>   >> Buildroot was created initially as a test-bed for uClibc, and also
>>   >> because uClibc made a lot of sense for embedded Linux systems, due to
>>   >> its smaller size and fine-grained configurability.
>>   >>
>>   >> Since then, the landscape of embedded Linux systems has changed. Even
>>   >> though Buildroot happily supports really low-end devices, the vast
>>   >> majority of Buildroot users are quite certainly running the resulting
>>   >> system on a reasonably powerful platform, with significant amount of
>>   >> RAM and storage. In this context, the benefits of uClibc are no longer
>>   >> that much relevant, and glibc causes less "troubles". Therefore, this
>>   >> patch proposes to use glibc as our default C library when using the
>>   >> internal toolchain backend instead of uClibc.
>>   >>
>>   >> Of course, we will keep the support for uClibc, which remains an
>>   >> important C library choice, for space-constrained systems, or simply
>>   >> for architectures that are not supported by glibc.
>>   >>
>>   >> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>>
>>   > Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
>>
>>   > Yes, I will be a bit sad that we demote uClibc-ng, but let's face it:
>>   > the word moves on, let's move along.
>>
>> Agreed.
>>
>> Acked-by: Peter Korsgaard <peter@korsgaard.com>
>>
> The next move is probably increase testing with glibc in the Buildroot testsuite?

  If you mean the autobuilder: no, not at all. Quoting James: we actually want 
the autobuilder tests to fail - passing tests are not "interesting". And uClibc 
and musl are much more likely to lead to failures.

  Regards,
  Arnout

> 
> Acked-by: Romain Naour <romain.naour@gmail.com>
> 
> Best regards,
> Romain
diff mbox series

Patch

diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
index 836af3b22a..9956dc4383 100644
--- a/toolchain/toolchain-buildroot/Config.in
+++ b/toolchain/toolchain-buildroot/Config.in
@@ -22,8 +22,7 @@  config BR2_TOOLCHAIN_BUILDROOT_VENDOR
 
 choice
 	prompt "C library"
-	default BR2_TOOLCHAIN_BUILDROOT_UCLIBC
-	default BR2_TOOLCHAIN_BUILDROOT_GLIBC if BR2_powerpc64
+	default BR2_TOOLCHAIN_BUILDROOT_GLIBC
 
 config BR2_TOOLCHAIN_BUILDROOT_UCLIBC
 	bool "uClibc-ng"