glibc: add version 2.24
PATCH 1/1 glibc: add version 2.24
--- package/glibc/Config.in | 6 ++++++ package/glibc/glibc.hash | 1 + 2 files changed, 7 insertions(+)
package/glibc/Config.in +6 -0
@@ -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
package/glibc/glibc.hash +1 -0
@@ -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
Signature · 1 line
2.7.3
PATCH 1/1 glibc: add version 2.24
Quoted 32 lines · Vicente Olivert Riera
Signed-off-by Vicente Olivert Riera <[email protected]>--- package/glibc/Config.in | 6 ++++++ package/glibc/glibc.hash | 1 + 2 files changed, 7 insertions(+)package/glibc/Config.in +6
-0@@ -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_24package/glibc/glibc.hash +0
-0
package/glibc/glibc.hash line 4
Quoted 4 lines
package/glibc/glibc.hash +1
-0@@ -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
PATCH 1/1 glibc: add version 2.24
Hello,
Quoted 6 lines · Khem Raj
Quoted 4 lines
# Locally calculated after checking pgp signature (glibc)
sha256eb731406903befef1d8f878a46be75ef862b9056ab0cde1626d08a7a05328948glibc-2.22.tar.xz
sha25694efeb00e4603c8546209cefb3e1a50a5315c86fa9b078b6fad758e187ce13e9glibc-2.23.tar.xz
+sha25699d4a3e8efd144d71488e478f62587578c0f4e1fa0b4eed47ee3d4975ebeb5d3glibc-2.23.tar.xztypo. 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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 glibc: add version 2.24
Hi Thomas,
Quoted 9 lines · Thomas Petazzoni
Hello,
Quoted 5 lines · Khem Raj
Quoted 4 lines
# Locally calculated after checking pgp signature (glibc)
sha256eb731406903befef1d8f878a46be75ef862b9056ab0cde1626d08a7a05328948glibc-2.22.tar.xz
sha25694efeb00e4603c8546209cefb3e1a50a5315c86fa9b078b6fad758e187ce13e9glibc-2.23.tar.xz
+sha25699d4a3e8efd144d71488e478f62587578c0f4e1fa0b4eed47ee3d4975ebeb5d3glibc-2.23.tar.xz
Quoted 5 lines
Quoted 1 line
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.
Quoted 3 lines
Thomas
PATCH 1/1 glibc: add version 2.24
In reply to Vicente Olivert RieraHello,
Quoted 11 lines · Vicente Olivert Riera
Signed-off-by Vicente Olivert Riera <[email protected]>--- package/glibc/Config.in | 6 ++++++ package/glibc/glibc.hash | 1 + 2 files changed, 7 insertions(+)package/glibc/Config.in +0
-0
package/glibc/Config.in config BR2_GLIBC_VERSION_2_23 · line 28
Quoted 7 lines
package/glibc/Config.in +4
-0@@ -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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 glibc: add version 2.24
Quoted 34 lines · Thomas Petazzoni
Hello,
Quoted 11 lines · Vicente Olivert Riera
Signed-off-by Vicente Olivert Riera <[email protected]>---
package/glibc/Config.in | 6 ++++++
package/glibc/glibc.hash | 1 +2 files changed, 7 insertions(+)package/glibc/Config.in +0
-0package/glibc/Config.in config BR2_GLIBC_VERSION_2_23 · line 28
Quoted 7 lines
package/glibc/Config.in +4
-0@@ -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_sparcOne 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.
Quoted 8 lines
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>
PATCH 1/1 glibc: add version 2.24
Hello,
Quoted 9 lines · Khem Raj
Quoted 3 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 glibc: add version 2.24
Quoted 14 lines · Thomas Petazzoni
Hello,
Quoted 9 lines · Khem Raj
Quoted 3 lines
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,
Quoted 7 lines
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.
PATCH 1/1 glibc: add version 2.24
Hello,
Quoted 2 lines · Khem Raj
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.
Quoted 3 lines
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.
Quoted 4 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 glibc: add version 2.24
In reply to Thomas PetazzoniThomas, All,
On 2016-08-05 18:53 +0200, Thomas Petazzoni spake thusly:
Quoted 29 lines · Vicente Olivert Riera
Quoted 11 lines
Signed-off-by Vicente Olivert Riera <[email protected]>--- package/glibc/Config.in | 6 ++++++ package/glibc/glibc.hash | 1 + 2 files changed, 7 insertions(+)package/glibc/Config.in +0
-0package/glibc/Config.in config BR2_GLIBC_VERSION_2_23 · line 28
Quoted 7 lines
package/glibc/Config.in +4
-0@@ -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_sparcOne 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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 11 lines
Best regards,
Thomas
Signature · 7 lines
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
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 glibc: add version 2.24
Hello,
Quoted 10 lines · Yann E. MORIN
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
Quoted 3 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 glibc: add version 2.24
Thomas, All,
On 2016-08-09 10:49 +0200, Thomas Petazzoni spake thusly:
Quoted 14 lines · Yann E. MORIN
Quoted 13 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 4 lines
- 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/
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 glibc: add version 2.24
Quoted 38 lines · Yann E. MORIN
Thomas, All,
On 2016-08-09 10:49 +0200, Thomas Petazzoni spake thusly:
Quoted 14 lines · Yann E. MORIN
Quoted 13 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 4 lines
- 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/Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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_Ysymbols 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 ?
Quoted 10 lines
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. |
Quoted 5 lines
'------------------------------^-------^------------------^--------------------'
_______________________________________________
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>
PATCH 1/1 glibc: add version 2.24
Khem, All,
On 2016-08-09 12:42 -0700, Khem Raj spake thusly:
Quoted 47 lines
Quoted 38 lines · Yann E. MORIN
Thomas, All,
On 2016-08-09 10:49 +0200, Thomas Petazzoni spake thusly:
Quoted 14 lines · Yann E. MORIN
Quoted 13 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 4 lines
- 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/Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
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.Quoted 8 lines
Quoted 2 lines
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_Ysymbols for the running kernel (not that we want to have them).
Quoted 3 lines
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.
Quoted 2 lines
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.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'