glibc: remove version choice
PATCH 1/1 glibc: remove version choice
We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library.
Add me as Maintainer for the package.
--- DEVELOPERS | 1 + .../glibc/0001-sh-Fix-building-with-gcc5-6.patch | 56 ++++++++++ package/glibc/2.23/0001-fix-CVE-2016-3075.patch | 47 -------- package/glibc/2.23/0002-gcc6.patch | 88 --------------- ...-fix-wrong-vfork-aliases-in-libpthread.so.patch | 76 ------------- ...more-fixes-to-the-vfork-aliases-in-libpth.patch | 122 --------------------- .../2.23/0005-sh-Fix-building-with-gcc5-6.patch | 56 ---------- .../2.24/0001-sh-Fix-building-with-gcc5-6.patch | 56 ---------- .../2.25/0001-sh-Fix-building-with-gcc5-6.patch | 56 ---------- package/glibc/Config.in | 29 +---- package/glibc/glibc.hash | 2 - package/glibc/glibc.mk | 2 +- 12 files changed, 59 insertions(+), 532 deletions(-) create mode 100644 package/glibc/0001-sh-Fix-building-with-gcc5-6.patch delete mode 100644 package/glibc/2.23/0001-fix-CVE-2016-3075.patch delete mode 100644 package/glibc/2.23/0002-gcc6.patch delete mode 100644 package/glibc/2.23/0003-MIPS-SPARC-fix-wrong-vfork-aliases-in-libpthread.so.patch delete mode 100644 package/glibc/2.23/0004-MIPS-SPARC-more-fixes-to-the-vfork-aliases-in-libpth.patch delete mode 100644 package/glibc/2.23/0005-sh-Fix-building-with-gcc5-6.patch delete mode 100644 package/glibc/2.24/0001-sh-Fix-building-with-gcc5-6.patch delete mode 100644 package/glibc/2.25/0001-sh-Fix-building-with-gcc5-6.patch
DEVELOPERS +1 -0
@@ -1686,6 +1686,7 @@ F: arch/Config.in.sparc F: package/uclibc/ F: package/uclibc-ng-test/ F: package/mksh/ +F: package/glibc/ N: Will Newton <[email protected]> F: package/enchant/
package/glibc/0001-sh-Fix-building-with-gcc5-6.patch new file +56 -0
56 lines not on this page · raw message
package/glibc/2.23/0001-fix-CVE-2016-3075.patch deleted +0 -47
47 lines not on this page · raw message
package/glibc/2.23/0002-gcc6.patch deleted +0 -88
88 lines not on this page · raw message
package/glibc/2.23/0003-MIPS-SPARC-fix-wrong-vfork-aliases-in-libpthread.so.patch deleted +0 -76
76 lines not on this page · raw message
package/glibc/2.23/0004-MIPS-SPARC-more-fixes-to-the-vfork-aliases-in-libpth.patch deleted +0 -122
122 lines not on this page · raw message
package/glibc/2.23/0005-sh-Fix-building-with-gcc5-6.patch deleted +0 -56
56 lines not on this page · raw message
package/glibc/2.24/0001-sh-Fix-building-with-gcc5-6.patch deleted +0 -56
56 lines not on this page · raw message
package/glibc/2.25/0001-sh-Fix-building-with-gcc5-6.patch deleted +0 -56
56 lines not on this page · raw message
package/glibc/Config.in +1 -28
@@ -3,35 +3,8 @@ if BR2_TOOLCHAIN_BUILDROOT_GLIBC config BR2_PACKAGE_GLIBC bool default y + depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2 select BR2_PACKAGE_LINUX_HEADERS select BR2_TOOLCHAIN_HAS_SSP -choice - prompt "glibc version" - default BR2_GLIBC_VERSION_2_24 - -config BR2_GLIBC_VERSION_2_23 - bool "2.23" - -config BR2_GLIBC_VERSION_2_24 - bool "2.24" - # Linux 3.2 or later kernel headers are required on all arches. - # See: https://sourceware.org/ml/libc-alpha/2016-08/msg00212.html - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2 - -config BR2_GLIBC_VERSION_2_25 - bool "2.25" - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2 - -comment "glibc-2.24+ needs kernel headers >= 3.2" - depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2 - -endchoice - endif - -config BR2_GLIBC_VERSION_STRING - string - default "2.23" if BR2_GLIBC_VERSION_2_23 - default "2.24" if BR2_GLIBC_VERSION_2_24 - default "2.25" if BR2_GLIBC_VERSION_2_25
package/glibc/glibc.hash +0 -2
@@ -1,4 +1,2 @@ # Locally calculated after checking pgp signature (glibc) -sha256 94efeb00e4603c8546209cefb3e1a50a5315c86fa9b078b6fad758e187ce13e9 glibc-2.23.tar.xz -sha256 99d4a3e8efd144d71488e478f62587578c0f4e1fa0b4eed47ee3d4975ebeb5d3 glibc-2.24.tar.xz sha256 067bd9bb3390e79aa45911537d13c3721f1d9d3769931a30c2681bfee66f23a0 glibc-2.25.tar.xz
package/glibc/glibc.mk +1 -1
@@ -4,7 +4,7 @@ # ################################################################################ -GLIBC_VERSION = $(call qstrip,$(BR2_GLIBC_VERSION_STRING)) +GLIBC_VERSION = 2.25 GLIBC_SITE = $(BR2_GNU_MIRROR)/libc GLIBC_SOURCE = glibc-$(GLIBC_VERSION).tar.xz GLIBC_SRC_SUBDIR = .
Signature · 1 line
2.1.4
PATCH 1/1 glibc: remove version choice
Hello,
Quoted 5 lines · Waldemar Brodkorb
We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library.
Add me as Maintainer for the package.Signed-off-by Waldemar Brodkorb <[email protected]>
On this one, I'd like to have the opinion of others. Arnout? Peter? Yann? What do you think about this?
I don't have a very clear-cut opinion about this one.
DEVELOPERS F: arch/Config.in.sparc · line 1689
Quoted 9 lines
DEVELOPERS +1
-0@@ -1686,6 +1686,7 @@ F: arch/Config.in.sparc F: package/uclibc/ F: package/uclibc-ng-test/ F: package/mksh/ +F: package/glibc/
Alphabetic ordering not correct here.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 glibc: remove version choice
Waldemar, Thomas, All,
On 2017-06-06 21:35 +0200, Thomas Petazzoni spake thusly:
Quoted 11 lines · Waldemar Brodkorb
Quoted 5 lines
We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library.
Add me as Maintainer for the package.Signed-off-by Waldemar Brodkorb <[email protected]>On this one, I'd like to have the opinion of others. Arnout? Peter? Yann? What do you think about this?
I don't have a very clear-cut opinion about this one.
Neither do I.
On principle, I agree that we should drop versions. But glibc is part of the toolchain, and the toolchain has always been special.
True, we do not have a version for uClibc-ng, but we do have some traction on the maintainer! ;-) So we know things are gonna be fixed soonish, or that we can grab a temporary backport, both very easily.
Not so much for glibc in my experience...
musl is another kind of thing, because it is (was?) moving relatively fast, and I am under the impression that the maintainers are somewhat amenable to some fixes.
Not so much for glibc in my experience...
So, I won't oppose the patch, not will I push for it...
Yep, that is a very clear-cut position... ;-]
Regards,
Yann E. MORIN.
Quoted 19 lines
DEVELOPERS F: arch/Config.in.sparc · line 1689
Quoted 9 lines
DEVELOPERS +1
-0@@ -1686,6 +1686,7 @@ F: arch/Config.in.sparc F: package/uclibc/ F: package/uclibc-ng-test/ F: package/mksh/ +F: package/glibc/Alphabetic ordering not correct here.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
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: remove version choice
Hi Yann,
Yann E. MORIN wrote,
Quoted 13 lines
Waldemar, Thomas, All,
On 2017-06-06 21:35 +0200, Thomas Petazzoni spake thusly:
Quoted 10 lines · Waldemar Brodkorb
Quoted 5 lines
We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library.
Add me as Maintainer for the package.Signed-off-by Waldemar Brodkorb <[email protected]>On this one, I'd like to have the opinion of others. Arnout? Peter? Yann? What do you think about this?
Quoted 6 lines
Quoted 1 line
I don't have a very clear-cut opinion about this one.
Neither do I.
On principle, I agree that we should drop versions. But glibc is part of the toolchain, and the toolchain has always been special.
It is special, but if we can reduce the whole sum of combinations, isn't that good? In case of C library, it seems to me that the lastest version is always the best one. There are fewer regressions then with changing binutils or gcc default.
Quoted 11 lines
True, we do not have a version for uClibc-ng, but we do have some traction on the maintainer! ;-) So we know things are gonna be fixed soonish, or that we can grab a temporary backport, both very easily.
Not so much for glibc in my experience...
musl is another kind of thing, because it is (was?) moving relatively fast, and I am under the impression that the maintainers are somewhat amenable to some fixes.
Not so much for glibc in my experience...
I am reading both mailinglists so at least I sometimes fishing interesting bugfixes, as for the sh4 issue.
If Thomas don't mind I would take musl also over. (DEVELOPERS file)
best regards
Waldemar
PATCH 1/1 glibc: remove version choice
Hello,
Quoted 7 lines · Waldemar Brodkorb
Quoted 2 lines
On principle, I agree that we should drop versions. But glibc is part of the toolchain, and the toolchain has always been special.
It is special, but if we can reduce the whole sum of combinations, isn't that good? In case of C library, it seems to me that the lastest version is always the best one. There are fewer regressions then with changing binutils or gcc default.
Yes, that's true.
Quoted 10 lines
Quoted 5 lines
musl is another kind of thing, because it is (was?) moving relatively fast, and I am under the impression that the maintainers are somewhat amenable to some fixes.
Not so much for glibc in my experience...
I am reading both mailinglists so at least I sometimes fishing interesting bugfixes, as for the sh4 issue.
If Thomas don't mind I would take musl also over. (DEVELOPERS file)
I don't mind at all. Especially since:
- Buildroot doesn't have a notion of "taking over". Indeed, multiple developers can be listed for a given package in the DEVELOPERS file.
- In practice, issues with C libraries are rarely reported by the autobuilders as being on the C library package itself. It's often another package that will fail to build (last example: gdbm).
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 glibc: remove version choice
In reply to Yann E. MORINQuoted 18 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
Waldemar, Thomas, All,
On 2017-06-06 21:35 +0200, Thomas Petazzoni spake thusly:Quoted 11 lines · Waldemar Brodkorb
Quoted 5 lines
We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library.
Add me as Maintainer for the package.Signed-off-by Waldemar Brodkorb <[email protected]>On this one, I'd like to have the opinion of others. Arnout? Peter? Yann? What do you think about this?
I don't have a very clear-cut opinion about this one.
Neither do I.
Quoted 8 lines
On principle, I agree that we should drop versions. But glibc is part of the toolchain, and the toolchain has always been special.
True, we do not have a version for uClibc-ng, but we do have some traction on the maintainer! ;-) So we know things are gonna be fixed soonish, or that we can grab a temporary backport, both very easily.
Not so much for glibc in my experience...
True, but I also don't recall any package breakage because of issues in newer glibc versions (as glibc is "standard").
I also don't feel strongly about it, but it is true that it would limit the number of combinations and be more in line with musl/uClibc-ng, so I'm OK with doing it.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 glibc: remove version choice
Quoted 14 lines · Peter Korsgaard
Quoted 14 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
Waldemar, Thomas, All,
On 2017-06-06 21:35 +0200, Thomas Petazzoni spake thusly:Quoted 10 lines · Waldemar Brodkorb
Quoted 5 lines
We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library.
Add me as Maintainer for the package.Signed-off-by Waldemar Brodkorb <[email protected]>On this one, I'd like to have the opinion of others. Arnout? Peter? Yann? What do you think about this?
Quoted 8 lines
Quoted 8 lines
Quoted 1 line
I don't have a very clear-cut opinion about this one.
Neither do I.
On principle, I agree that we should drop versions. But glibc is part of the toolchain, and the toolchain has always been special.
True, we do not have a version for uClibc-ng,
I think there is in fact more reason to have multiple versions for uClibc-ng
than for glibc. Multiple versions are useful in any situation when there are ABI changes in the newer version so that binaries linked with the older version no longer work. glibc is very careful about ABI changes, uClibc-ng somewhat less so.
So yes, I'm in favour of removing this version choice. Also for binutils, by
the way. Yes, there may be regressions, but then those should be fixed, not swept under the carpet for some time until the new version becomes the default.
GCC is different, because newer GCC versions do break compatibility with older
libraries, and they do break existing (badly written) source code. In that sense I think it was a bad idea to remove GCC 4.9, because GCC 5 did break binary compatibility for C++... But I wasn't here at the time and that ship has sailed now.
Quoted 8 lines
Quoted 5 lines
but we do have some
traction on the maintainer! ;-) So we know things are gonna be fixed soonish, or that we can grab a temporary backport, both very easily.Not so much for glibc in my experience...
True, but I also don't recall any package breakage because of issues in newer glibc versions (as glibc is "standard").
I think mostly because they release much more slowly.
Regards,
Arnout
Quoted 3 lines
I also don't feel strongly about it, but it is true that it would limit the number of combinations and be more in line with musl/uClibc-ng, so I'm OK with doing it.
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 glibc: remove version choice
Hello,
Quoted 5 lines · Arnout Vandecappelle
I think there is in fact more reason to have multiple versions for uClibc-ng
than for glibc. Multiple versions are useful in any situation when there are ABI changes in the newer version so that binaries linked with the older version no longer work. glibc is very careful about ABI changes, uClibc-ng somewhat less so.
Quoted 8 lines
So yes, I'm in favour of removing this version choice. Also for binutils, by
the way. Yes, there may be regressions, but then those should be fixed, not swept under the carpet for some time until the new version becomes the default.GCC is different, because newer GCC versions do break compatibility with older
libraries, and they do break existing (badly written) source code. In that sense I think it was a bad idea to remove GCC 4.9, because GCC 5 did break binary compatibility for C++... But I wasn't here at the time and that ship has sailed now.
I haven't merged https://patchwork.ozlabs.org/patch/767087/, so gcc 4.9 is still there:
$ grep 4_9_X package/gcc/Config.in.host config BR2_GCC_VERSION_4_9_X default "4.9.4" if BR2_GCC_VERSION_4_9_X
I was waiting for feedback (such as yours) before merging this patch.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 glibc: remove version choice
In reply to Waldemar BrodkorbHi Waldemar,
As noted elsewhere, I'm positive about this patch, just a few additional
comments on top of Thomas's.
Quoted 3 lines · Waldemar Brodkorb
We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library.
Add me as Maintainer for the package.
Whenever a Config.in symbol is removed, the commit message should explain why
legacy handling is not needed:
Legacy handling is not needed: we only take away choice from the user, existing configs will still work the same. The only thing may change is the glibc version, but version changes are "normal" for packages.
Quoted 17 lines
Signed-off-by Waldemar Brodkorb <[email protected]>--- DEVELOPERS | 1 + .../glibc/0001-sh-Fix-building-with-gcc5-6.patch | 56 ++++++++++ package/glibc/2.23/0001-fix-CVE-2016-3075.patch | 47 -------- package/glibc/2.23/0002-gcc6.patch | 88 --------------- ...-fix-wrong-vfork-aliases-in-libpthread.so.patch | 76 ------------- ...more-fixes-to-the-vfork-aliases-in-libpth.patch | 122 --------------------- .../2.23/0005-sh-Fix-building-with-gcc5-6.patch | 56 ---------- .../2.24/0001-sh-Fix-building-with-gcc5-6.patch | 56 ---------- .../2.25/0001-sh-Fix-building-with-gcc5-6.patch | 56 ---------- package/glibc/Config.in | 29 +---- package/glibc/glibc.hash | 2 - package/glibc/glibc.mk | 2 +- 12 files changed, 59 insertions(+), 532 deletions(-) create mode 100644 package/glibc/0001-sh-Fix-building-with-gcc5-6.patch
Please use 'git format-patch -M' to enable rename detection, so that we can
easily see that nothing changed in the patch.
Regards,
Arnout
Quoted 7 lines
delete mode 100644 package/glibc/2.23/0001-fix-CVE-2016-3075.patch delete mode 100644 package/glibc/2.23/0002-gcc6.patch delete mode 100644 package/glibc/2.23/0003-MIPS-SPARC-fix-wrong-vfork-aliases-in-libpthread.so.patch delete mode 100644 package/glibc/2.23/0004-MIPS-SPARC-more-fixes-to-the-vfork-aliases-in-libpth.patch delete mode 100644 package/glibc/2.23/0005-sh-Fix-building-with-gcc5-6.patch delete mode 100644 package/glibc/2.24/0001-sh-Fix-building-with-gcc5-6.patch delete mode 100644 package/glibc/2.25/0001-sh-Fix-building-with-gcc5-6.patch
[snip]
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF