[Buildroot] [PATCH] glibc: add version 2.24

[Buildroot] [PATCH] glibc: add version 2.24

[Vicente Olivert Riera]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
 package/glibc/Config.in  | 6 ++++++
 package/glibc/glibc.hash | 1 +
 2 files changed, 7 insertions(+)

diff --git a/package/glibc/Config.in b/package/glibc/Config.in
index f86822d..a9a6cc7 100644
--- a/package/glibc/Config.in
+++ b/package/glibc/Config.in
@@ -22,6 +22,11 @@ config BR2_GLIBC_VERSION_2_23
 	# No support for pthread barriers on < v9 ISA
 	depends on !BR2_sparc
 
+config BR2_GLIBC_VERSION_2_24
+	bool "2.24"
+	# No support for pthread barriers on < v9 ISA
+	depends on !BR2_sparc
+
 endchoice
 
 endif
@@ -30,3 +35,4 @@ config BR2_GLIBC_VERSION_STRING
 	string
 	default "2.22" if BR2_GLIBC_VERSION_2_22
 	default "2.23" if BR2_GLIBC_VERSION_2_23
+	default "2.24" if BR2_GLIBC_VERSION_2_24
diff --git a/package/glibc/glibc.hash b/package/glibc/glibc.hash
index 052f281..3c5c612 100644
--- a/package/glibc/glibc.hash
+++ b/package/glibc/glibc.hash
@@ -1,3 +1,4 @@
 # Locally calculated after checking pgp signature (glibc)
 sha256	eb731406903befef1d8f878a46be75ef862b9056ab0cde1626d08a7a05328948	glibc-2.22.tar.xz
 sha256	94efeb00e4603c8546209cefb3e1a50a5315c86fa9b078b6fad758e187ce13e9	glibc-2.23.tar.xz
+sha256	99d4a3e8efd144d71488e478f62587578c0f4e1fa0b4eed47ee3d4975ebeb5d3	glibc-2.23.tar.xz
-- 
2.7.3

[Buildroot] [PATCH] glibc: add version 2.24

[Khem Raj]

On 8/5/16 1:59 AM, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>  package/glibc/Config.in  | 6 ++++++
>  package/glibc/glibc.hash | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/package/glibc/Config.in b/package/glibc/Config.in
> index f86822d..a9a6cc7 100644
> --- a/package/glibc/Config.in
> +++ b/package/glibc/Config.in
> @@ -22,6 +22,11 @@ config BR2_GLIBC_VERSION_2_23
>  	# No support for pthread barriers on < v9 ISA
>  	depends on !BR2_sparc
>  
> +config BR2_GLIBC_VERSION_2_24
> +	bool "2.24"
> +	# No support for pthread barriers on < v9 ISA
> +	depends on !BR2_sparc
> +
>  endchoice
>  
>  endif
> @@ -30,3 +35,4 @@ config BR2_GLIBC_VERSION_STRING
>  	string
>  	default "2.22" if BR2_GLIBC_VERSION_2_22
>  	default "2.23" if BR2_GLIBC_VERSION_2_23
> +	default "2.24" if BR2_GLIBC_VERSION_2_24
> diff --git a/package/glibc/glibc.hash b/package/glibc/glibc.hash
> index 052f281..3c5c612 100644
> --- a/package/glibc/glibc.hash
> +++ b/package/glibc/glibc.hash
> @@ -1,3 +1,4 @@
>  # Locally calculated after checking pgp signature (glibc)
>  sha256	eb731406903befef1d8f878a46be75ef862b9056ab0cde1626d08a7a05328948	glibc-2.22.tar.xz
>  sha256	94efeb00e4603c8546209cefb3e1a50a5315c86fa9b078b6fad758e187ce13e9	glibc-2.23.tar.xz
> +sha256	99d4a3e8efd144d71488e478f62587578c0f4e1fa0b4eed47ee3d4975ebeb5d3	glibc-2.23.tar.xz


typo. It should be 2.24

[Buildroot] [PATCH] glibc: add version 2.24

[Thomas Petazzoni]

Hello,

On Fri, 5 Aug 2016 07:33:15 -0700, Khem Raj wrote:

> >  # Locally calculated after checking pgp signature (glibc)
> >  sha256	eb731406903befef1d8f878a46be75ef862b9056ab0cde1626d08a7a05328948	glibc-2.22.tar.xz
> >  sha256	94efeb00e4603c8546209cefb3e1a50a5315c86fa9b078b6fad758e187ce13e9	glibc-2.23.tar.xz
> > +sha256	99d4a3e8efd144d71488e478f62587578c0f4e1fa0b4eed47ee3d4975ebeb5d3	glibc-2.23.tar.xz  
> 
> typo. It should be 2.24

Right. And this means that the patch was not even built-tested, as
Buildroot bails out when there is a .hash file for a package, but no
hash matching the file that has been downloaded.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] glibc: add version 2.24

[Vicente Olivert Riera]

Hi Thomas,

On 05/08/16 17:54, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 5 Aug 2016 07:33:15 -0700, Khem Raj wrote:
> 
>>>  # Locally calculated after checking pgp signature (glibc)
>>>  sha256	eb731406903befef1d8f878a46be75ef862b9056ab0cde1626d08a7a05328948	glibc-2.22.tar.xz
>>>  sha256	94efeb00e4603c8546209cefb3e1a50a5315c86fa9b078b6fad758e187ce13e9	glibc-2.23.tar.xz
>>> +sha256	99d4a3e8efd144d71488e478f62587578c0f4e1fa0b4eed47ee3d4975ebeb5d3	glibc-2.23.tar.xz  
>>
>> typo. It should be 2.24
> 
> Right. And this means that the patch was not even built-tested, as
> Buildroot bails out when there is a .hash file for a package, but no
> hash matching the file that has been downloaded.

not true. The patch was build tested, but before sending the patch to
the ML I modified the hash file, because what I did was to remove the
tabs in that file and change them by white spaces in the three lines. At
the end I decided to just make the minimal modifications, that's why
"checkout --"'ed that file and modified it again, forgetting to change
the filename.

Regards,

Vincent.

> 
> Thomas
> 

[Buildroot] [PATCH] glibc: add version 2.24

[Thomas Petazzoni]

Hello,

On Fri, 5 Aug 2016 09:59:27 +0100, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>  package/glibc/Config.in  | 6 ++++++
>  package/glibc/glibc.hash | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/package/glibc/Config.in b/package/glibc/Config.in
> index f86822d..a9a6cc7 100644
> --- a/package/glibc/Config.in
> +++ b/package/glibc/Config.in
> @@ -22,6 +22,11 @@ config BR2_GLIBC_VERSION_2_23
>  	# No support for pthread barriers on < v9 ISA
>  	depends on !BR2_sparc
>  
> +config BR2_GLIBC_VERSION_2_24
> +	bool "2.24"
> +	# No support for pthread barriers on < v9 ISA
> +	depends on !BR2_sparc

One thing important I notice in the release announcement of 2.24 is:

* The minimum Linux kernel version that this version of the GNU C Library
  can be used with is 3.2, except on i[4567]86 and x86_64, where Linux
  kernel version 2.6.32 or later suffices (on architectures that already
  required kernel versions more recent than 3.2, those requirements remain
  unchanged).  Linux 3.2 or later kernel headers are required on all
  architectures.

It is not written completely clearly: they first say that on
x86/x86-64, 2.6.32 is sufficient, but they conclude that 3.2 is the
minimum version on all architectures. It would be good to clarify this
aspect.

Regardless of this detail, this means we will have to encode this
dependency somehow. Indeed, we still have people using kernels older
than 3.2 I believe on various platforms.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] glibc: add version 2.24

[Khem Raj]

> On Aug 5, 2016, at 9:53 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> 
> Hello,
> 
> On Fri, 5 Aug 2016 09:59:27 +0100, Vicente Olivert Riera wrote:
>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>> ---
>> package/glibc/Config.in  | 6 ++++++
>> package/glibc/glibc.hash | 1 +
>> 2 files changed, 7 insertions(+)
>> 
>> diff --git a/package/glibc/Config.in b/package/glibc/Config.in
>> index f86822d..a9a6cc7 100644
>> --- a/package/glibc/Config.in
>> +++ b/package/glibc/Config.in
>> @@ -22,6 +22,11 @@ config BR2_GLIBC_VERSION_2_23
>> 	# No support for pthread barriers on < v9 ISA
>> 	depends on !BR2_sparc
>> 
>> +config BR2_GLIBC_VERSION_2_24
>> +	bool "2.24"
>> +	# No support for pthread barriers on < v9 ISA
>> +	depends on !BR2_sparc
> 
> One thing important I notice in the release announcement of 2.24 is:
> 
> * The minimum Linux kernel version that this version of the GNU C Library
>  can be used with is 3.2, except on i[4567]86 and x86_64, where Linux
>  kernel version 2.6.32 or later suffices (on architectures that already
>  required kernel versions more recent than 3.2, those requirements remain
>  unchanged).  Linux 3.2 or later kernel headers are required on all
>  architectures.
> 
> It is not written completely clearly: they first say that on
> x86/x86-64, 2.6.32 is sufficient, but they conclude that 3.2 is the
> minimum version on all architectures. It would be good to clarify this
> aspect.
> 
> Regardless of this detail, this means we will have to encode this
> dependency somehow. Indeed, we still have people using kernels older
> than 3.2 I believe on various platforms.

thats right. perhaps --enable-kernel=3.2.0 conditional on version being
2.24 in glibc mk file would put in a runtime check where apps would fail
to run on older kernels. If you want to detect it at build time then you
need to insert a mechanism to parse the kernel version of the build and
then compare that against kernel version used with --enable-kernel,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160805/b94541fe/attachment.asc>

[Buildroot] [PATCH] glibc: add version 2.24

[Thomas Petazzoni]

Hello,

On Fri, 5 Aug 2016 13:58:12 -0700, Khem Raj wrote:

> > Regardless of this detail, this means we will have to encode this
> > dependency somehow. Indeed, we still have people using kernels older
> > than 3.2 I believe on various platforms.  
> 
> thats right. perhaps --enable-kernel=3.2.0 conditional on version being
> 2.24 in glibc mk file would put in a runtime check where apps would fail
> to run on older kernels. If you want to detect it at build time then you
> need to insert a mechanism to parse the kernel version of the build and
> then compare that against kernel version used with --enable-kernel,

I'm not really talking of build time detection, but rather referring to
the fact that we have Config.in options in Buildroot that tell us the
version of the kernel headers. So maybe glibc 2.24 should depend on
kernel headers >= 3.2.0. For now, we'll keep glibc 2.23, but then some
time later in the future, when 2.24 becomes the oldest supported glibc
version, glibc as a whole will be usable only for >= 3.2.0. Hopefully
by that time, all the people will have moved to newer kernels :)

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] glibc: add version 2.24

[Khem Raj]

On 16-08-05 23:17:47, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 5 Aug 2016 13:58:12 -0700, Khem Raj wrote:
> 
> > > Regardless of this detail, this means we will have to encode this
> > > dependency somehow. Indeed, we still have people using kernels older
> > > than 3.2 I believe on various platforms.  
> > 
> > thats right. perhaps --enable-kernel=3.2.0 conditional on version being
> > 2.24 in glibc mk file would put in a runtime check where apps would fail
> > to run on older kernels. If you want to detect it at build time then you
> > need to insert a mechanism to parse the kernel version of the build and
> > then compare that against kernel version used with --enable-kernel,
> 
> I'm not really talking of build time detection, but rather referring to
> the fact that we have Config.in options in Buildroot that tell us the
> version of the kernel headers. So maybe glibc 2.24 should depend on
> kernel headers >= 3.2.0. For now, we'll keep glibc 2.23, but then some
> time later in the future, when 2.24 becomes the oldest supported glibc
> version, glibc as a whole will be usable only for >= 3.2.0. Hopefully
> by that time, all the people will have moved to newer kernels :)

Its just not kernel headers, infact its the kernel proper version as well
which should be >= 3.2.0

you should also use --enable-kernel switch to detect the case where
someone might be using older kernel with glibc 2.24 and running into
issues at runtime.

IMO BR should deprecate older versions more agressively, and keep them
only on need basis. May be its against the objectives of the project
but you will be spread thin supporting so many combinations and
how to test them all.

[Buildroot] [PATCH] glibc: add version 2.24

[Thomas Petazzoni]

Hello,

On Fri, 5 Aug 2016 14:25:01 -0700, Khem Raj wrote:

> Its just not kernel headers, infact its the kernel proper version as well
> which should be >= 3.2.0

Well, if your kernel headers are version X, surely you're running a
kernel >= X.

> you should also use --enable-kernel switch to detect the case where
> someone might be using older kernel with glibc 2.24 and running into
> issues at runtime.

As said above, we make the assumption that if kernel headers version X
were used, the user is running a kernel of version >= X.

> IMO BR should deprecate older versions more agressively, and keep them
> only on need basis. May be its against the objectives of the project
> but you will be spread thin supporting so many combinations and
> how to test them all.

We already deprecate older versions quite aggressively. We're currently
using glibc 2.23 (the latest until today), the latest uclibc-ng, the
latest musl. We haven't switched to gcc 5 as the default yet (we're on
gcc 4.9), but I'm planning on moving to gcc 5 as the default for the
next Buildroot release, i.e 2016.11.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] glibc: add version 2.24

[Yann E. MORIN]

Thomas, All,

On 2016-08-05 18:53 +0200, Thomas Petazzoni spake thusly:
> On Fri, 5 Aug 2016 09:59:27 +0100, Vicente Olivert Riera wrote:
> > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> > ---
> >  package/glibc/Config.in  | 6 ++++++
> >  package/glibc/glibc.hash | 1 +
> >  2 files changed, 7 insertions(+)
> > 
> > diff --git a/package/glibc/Config.in b/package/glibc/Config.in
> > index f86822d..a9a6cc7 100644
> > --- a/package/glibc/Config.in
> > +++ b/package/glibc/Config.in
> > @@ -22,6 +22,11 @@ config BR2_GLIBC_VERSION_2_23
> >  	# No support for pthread barriers on < v9 ISA
> >  	depends on !BR2_sparc
> >  
> > +config BR2_GLIBC_VERSION_2_24
> > +	bool "2.24"
> > +	# No support for pthread barriers on < v9 ISA
> > +	depends on !BR2_sparc
> 
> One thing important I notice in the release announcement of 2.24 is:
> 
> * The minimum Linux kernel version that this version of the GNU C Library
>   can be used with is 3.2, except on i[4567]86 and x86_64, where Linux
>   kernel version 2.6.32 or later suffices (on architectures that already
>   required kernel versions more recent than 3.2, those requirements remain
>   unchanged).  Linux 3.2 or later kernel headers are required on all
>   architectures.
> 
> It is not written completely clearly: they first say that on
> x86/x86-64, 2.6.32 is sufficient, but they conclude that 3.2 is the
> minimum version on all architectures. It would be good to clarify this
> aspect.

What this means, at least what I understand it means, is that:

  - glibc 2.24 will not *run* on kernels more ancient than 3.2, except on
    x86/x86_64, when it will not run on kernels older than 2.6.32.

    This is a runtime dependency.

  - glibc needs kernel headers 3.2 (or later) for all architectures,
    even for x86/x86_64.

    This is a built-time dependency.

Note the apparent discrepancy betwen the runtime kernel and the
build-time headers for x86/x86_64.

That's because glibc has fall-back code to run on kernel older than the
ones used for the headers (unless the --enable-kernel configure option
is passed, of course).

At least, that what I understand from that comment; but indeed, it is
not very explicit.

> Regardless of this detail, this means we will have to encode this
> dependency somehow. Indeed, we still have people using kernels older
> than 3.2 I believe on various platforms.

On all but x86_x86_64, yes.

Regards,
Yann E. MORIN.

> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] glibc: add version 2.24

[Thomas Petazzoni]

Hello,

On Mon, 8 Aug 2016 18:42:09 +0200, Yann E. MORIN wrote:

> > It is not written completely clearly: they first say that on
> > x86/x86-64, 2.6.32 is sufficient, but they conclude that 3.2 is the
> > minimum version on all architectures. It would be good to clarify this
> > aspect.  
> 
> What this means, at least what I understand it means, is that:
> 
>   - glibc 2.24 will not *run* on kernels more ancient than 3.2, except on
>     x86/x86_64, when it will not run on kernels older than 2.6.32.
> 
>     This is a runtime dependency.
> 
>   - glibc needs kernel headers 3.2 (or later) for all architectures,
>     even for x86/x86_64.
> 
>     This is a built-time dependency.

OK. From Buildroot's perspective, all what matters is the build-time
dependency. If the 3.2 kernel headers are needed to build glibc 2.24,
then glibc 2.24 should depend on headers >= 3.2.

> > Regardless of this detail, this means we will have to encode this
> > dependency somehow. Indeed, we still have people using kernels older
> > than 3.2 I believe on various platforms.  
> 
> On all but x86_x86_64, yes.

I don't get this. From my point of view, the x86/x86_64 "exception" is
of no use to us: all we are interested in is the build-time dependency.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] glibc: add version 2.24

[Yann E. MORIN]

Thomas, All,

On 2016-08-09 10:49 +0200, Thomas Petazzoni spake thusly:
> On Mon, 8 Aug 2016 18:42:09 +0200, Yann E. MORIN wrote:
> 
> > > It is not written completely clearly: they first say that on
> > > x86/x86-64, 2.6.32 is sufficient, but they conclude that 3.2 is the
> > > minimum version on all architectures. It would be good to clarify this
> > > aspect.  
> > 
> > What this means, at least what I understand it means, is that:
> > 
> >   - glibc 2.24 will not *run* on kernels more ancient than 3.2, except on
> >     x86/x86_64, when it will not run on kernels older than 2.6.32.
> > 
> >     This is a runtime dependency.
> > 
> >   - glibc needs kernel headers 3.2 (or later) for all architectures,
> >     even for x86/x86_64.
> > 
> >     This is a built-time dependency.
> 
> OK. From Buildroot's perspective, all what matters is the build-time
> dependency. If the 3.2 kernel headers are needed to build glibc 2.24,
> then glibc 2.24 should depend on headers >= 3.2.

Yes. That's what Vicente did in his v3 of his patch:
    https://patchwork.ozlabs.org/patch/657159/

> > > Regardless of this detail, this means we will have to encode this
> > > dependency somehow. Indeed, we still have people using kernels older
> > > than 3.2 I believe on various platforms.  
> > 
> > On all but x86_x86_64, yes.
> 
> I don't get this. From my point of view, the x86/x86_64 "exception" is
> of no use to us: all we are interested in is the build-time dependency.

Well, I mixed it a bit in my head... What I was thinking was that we
should still allow building a glibc-based toolchain even if the running
kernel was older than 3.2 for x86/x86_64. But we have no way to enforce
that: we have no _AT_LEAST_X_Y symbols for the running kernel (not that
we want to have them).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] glibc: add version 2.24

[Khem Raj]

> On Aug 9, 2016, at 12:33 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> 
> Thomas, All,
> 
> On 2016-08-09 10:49 +0200, Thomas Petazzoni spake thusly:
>> On Mon, 8 Aug 2016 18:42:09 +0200, Yann E. MORIN wrote:
>> 
>>>> It is not written completely clearly: they first say that on
>>>> x86/x86-64, 2.6.32 is sufficient, but they conclude that 3.2 is the
>>>> minimum version on all architectures. It would be good to clarify this
>>>> aspect.
>>> 
>>> What this means, at least what I understand it means, is that:
>>> 
>>>  - glibc 2.24 will not *run* on kernels more ancient than 3.2, except on
>>>    x86/x86_64, when it will not run on kernels older than 2.6.32.
>>> 
>>>    This is a runtime dependency.
>>> 
>>>  - glibc needs kernel headers 3.2 (or later) for all architectures,
>>>    even for x86/x86_64.
>>> 
>>>    This is a built-time dependency.
>> 
>> OK. From Buildroot's perspective, all what matters is the build-time
>> dependency. If the 3.2 kernel headers are needed to build glibc 2.24,
>> then glibc 2.24 should depend on headers >= 3.2.
> 
> Yes. That's what Vicente did in his v3 of his patch:
>    https://patchwork.ozlabs.org/patch/657159/
> 
>>>> Regardless of this detail, this means we will have to encode this
>>>> dependency somehow. Indeed, we still have people using kernels older
>>>> than 3.2 I believe on various platforms.
>>> 
>>> On all but x86_x86_64, yes.
>> 
>> I don't get this. From my point of view, the x86/x86_64 "exception" is
>> of no use to us: all we are interested in is the build-time dependency.
> 
> Well, I mixed it a bit in my head... What I was thinking was that we
> should still allow building a glibc-based toolchain even if the running
> kernel was older than 3.2 for x86/x86_64. But we have no way to enforce
> that: we have no _AT_LEAST_X_Y symbols for the running kernel (not that
> we want to have them).

you can in theory use --enable-kernel=VERSION to configure glibc in order
to indicate minimum kernel it can run on, older than that will be flagged
at runtime practically, are there BR users who want to stick to such
an old kernel on x86 and use latest BR with glibc 2.24 ?

> 
> Regards,
> Yann E. MORIN.
> 
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160809/e256fdf7/attachment.asc>

[Buildroot] [PATCH] glibc: add version 2.24

[Yann E. MORIN]

Khem, All,

On 2016-08-09 12:42 -0700, Khem Raj spake thusly:
> 
> > On Aug 9, 2016, at 12:33 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > 
> > Thomas, All,
> > 
> > On 2016-08-09 10:49 +0200, Thomas Petazzoni spake thusly:
> >> On Mon, 8 Aug 2016 18:42:09 +0200, Yann E. MORIN wrote:
> >> 
> >>>> It is not written completely clearly: they first say that on
> >>>> x86/x86-64, 2.6.32 is sufficient, but they conclude that 3.2 is the
> >>>> minimum version on all architectures. It would be good to clarify this
> >>>> aspect.
> >>> 
> >>> What this means, at least what I understand it means, is that:
> >>> 
> >>>  - glibc 2.24 will not *run* on kernels more ancient than 3.2, except on
> >>>    x86/x86_64, when it will not run on kernels older than 2.6.32.
> >>> 
> >>>    This is a runtime dependency.
> >>> 
> >>>  - glibc needs kernel headers 3.2 (or later) for all architectures,
> >>>    even for x86/x86_64.
> >>> 
> >>>    This is a built-time dependency.
> >> 
> >> OK. From Buildroot's perspective, all what matters is the build-time
> >> dependency. If the 3.2 kernel headers are needed to build glibc 2.24,
> >> then glibc 2.24 should depend on headers >= 3.2.
> > 
> > Yes. That's what Vicente did in his v3 of his patch:
> >    https://patchwork.ozlabs.org/patch/657159/
> > 
> >>>> Regardless of this detail, this means we will have to encode this
> >>>> dependency somehow. Indeed, we still have people using kernels older
> >>>> than 3.2 I believe on various platforms.
> >>> 
> >>> On all but x86_x86_64, yes.
> >> 
> >> I don't get this. From my point of view, the x86/x86_64 "exception" is
> >> of no use to us: all we are interested in is the build-time dependency.
> > 
> > Well, I mixed it a bit in my head... What I was thinking was that we
> > should still allow building a glibc-based toolchain even if the running
> > kernel was older than 3.2 for x86/x86_64. But we have no way to enforce
> > that: we have no _AT_LEAST_X_Y symbols for the running kernel (not that
> > we want to have them).
> 
> you can in theory use --enable-kernel=VERSION to configure glibc in order
> to indicate minimum kernel it can run on, older than that will be flagged
> at runtime practically,

Well, yes indeed, but do we care to support that? There are cases where
we do not and can't know the version of the kernel the user will be
running on (because he builds the kernel outside of Buidlroot, for
whatever reason).

So we just let glibc configure itself for the oldest kernel it can
support on the targeted arch.

I even doubt it would make sense to have such a knob for size reasons.
glibc is already big, and I doubt removing fallbacks for older kernels
would gain much more than a few KiBs. At best.

> are there BR users who want to stick to such
> an old kernel on x86 and use latest BR with glibc 2.24 ?

Yes. There are BSPs out there that are stuck on 3.0. I even know of some
that are even stuck to some 2.6.18-ish... :-(

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'