[Buildroot] [PATCH] add basic support for uClibc-ng

Thomas De Schampheleire patrickdepinguin at gmail.com
Wed Feb 11 09:35:16 UTC 2015


Hi Thomas,

On Mon, Feb 9, 2015 at 8:53 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Dear Waldemar Brodkorb,
>
> On Mon, 9 Feb 2015 19:16:37 +0100, Waldemar Brodkorb wrote:
>
>> +config BR2_TOOLCHAIN_BUILDROOT_UCLIBC_NG
>> +     bool "uClibc-ng"
>> +     select BR2_TOOLCHAIN_USES_UCLIBC
>> +     depends on BR2_arcle   || BR2_arceb  || BR2_arm    || BR2_armeb    || \
>> +                BR2_avr32   || BR2_bfin   || BR2_i386   || BR2_m68k     || \
>> +                BR2_mips    || BR2_mipsel || BR2_mips64 || BR2_mips64el || \
>> +                BR2_powerpc || BR2_sh     || BR2_sparc  || BR2_xtensa   || \
>> +                BR2_x86_64
>> +     help
>> +       This option selects uClibc-ng as the C library for the
>> +       cross-compilation toolchain.
>> +
>> +       http://uclibc-ng.org
>> +
>
> I don't think introducing this symbol is needed. Instead, we can just
> make uClibc-ng another version of uClibc. Like the following (untested) :
>
> diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
> index 020c47c..6f96c15 100644
> --- a/package/uclibc/Config.in
> +++ b/package/uclibc/Config.in
> @@ -21,6 +21,10 @@ choice
>                 bool "uClibc 0.9.33.x"
>                 depends on !(BR2_arc || BR2_avr32 || BR2_xtensa)
>
> +       config BR2_UCLIBC_NG_VERSION_1_0_0
> +               bool "uClibc-ng 1.0.0"
> +               depends on !(BR2_arc || BR2_avr32 || BR2_xtensa)
> +
>         config BR2_UCLIBC_VERSION_XTENSA_GIT
>                 bool "uClibc Git Xtensa"
>                 depends on BR2_xtensa
> @@ -42,6 +46,7 @@ config BR2_UCLIBC_VERSION_STRING
>         string
>         default 0.9.31.1        if BR2_UCLIBC_VERSION_0_9_31
>         default 0.9.33.2        if BR2_UCLIBC_VERSION_0_9_33
> +       default 1.0.0           if BR2_UCLIBC_NG_VERSION_1_0_0

This creates a conflict when the uClibc project decides that they too
should release a 1.0.0.
It could be avoided by appending/prepending an 'ng' suffix/prefix, but
it would need to be stripped out in uclibc.mk.

>         default "arc-2014.12" if BR2_arc
>         default "7bf35c8b7d4a1f97174eb49f47f33946b282114c" if BR2_UCLIBC_VERSION_XTENSA_GIT
>         default BR2_USE_UCLIBC_SNAPSHOT if BR2_UCLIBC_VERSION_SNAPSHOT
> @@ -50,6 +55,7 @@ config BR2_UCLIBC_CONFIG
>         string "uClibc configuration file to use?"
>         default "package/uclibc/uClibc-0.9.31.config" if BR2_UCLIBC_VERSION_0_9_31
>         default "package/uclibc/uClibc-0.9.33.config" if BR2_UCLIBC_VERSION_0_9_33
> +       default "package/uclibc/uClibc-ng-1.0.0.config" if BR2_UCLIBC_NG_VERSION_1_0_0
>         default "package/uclibc/uClibc-snapshot.config" if BR2_arc
>         default "package/uclibc/uClibc-snapshot.config" if BR2_UCLIBC_VERSION_SNAPSHOT
>         default "package/uclibc/uClibc-snapshot.config" if BR2_UCLIBC_VERSION_XTENSA_GIT
> diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
> index 8654926..aeffa18 100644
> --- a/package/uclibc/uclibc.mk
> +++ b/package/uclibc/uclibc.mk
> @@ -17,6 +17,9 @@ UCLIBC_SOURCE = uClibc-$(UCLIBC_VERSION).tar.gz
>  else ifeq ($(BR2_UCLIBC_VERSION_XTENSA_GIT),y)
>  UCLIBC_SITE = git://git.busybox.net/uClibc
>  UCLIBC_SOURCE = uClibc-$(UCLIBC_VERSION).tar.gz
> +else ifeq ($(BR2_UCLIBC_NG_VERSION_1_0_0),y)
> +UCLIBC_SITE = http://downloads.uclibc-ng.org/releases/1.0.0/
> +UCLIBC_SOURCE = uClibc-ng-$(UCLIBC_VERSION).tar.xz

Also this is not very future-proof I think, suppose Waldemar releases
1.0.1, 1.0.2 and 1.1.0 shortly, then we would have three extra ifeq
blocks here?

It could be nicer to introduce a 'uclibc variant' option, which is a
middle-ground between Waldemar's original patching creating a separate
c library, and your proposal of treating just the version different.
A separate UCLIBC_VERSION would be created without separate
prefix/postfix. So a uclibc version of 1.0.0 would not clash with
uclibc-ng version 1.0.0. In uclibc.mk the SITE/SOURCE would be filled
based on the variant, and the version can then be used without
transformation.

What do you think of that?

Best regards,
Thomas


More information about the buildroot mailing list