diff mbox

eglibc: bump to version 2.19 SVN R25243

Message ID 1396875879-22199-1-git-send-email-gustavo@zacarias.com.ar
State Changes Requested
Headers show

Commit Message

Gustavo Zacarias April 7, 2014, 1:04 p.m. UTC
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 .../2.18-svnr23787/glibc-0001-accept-make4.patch   | 33 ----------------------
 package/glibc/glibc.mk                             |  2 +-
 2 files changed, 1 insertion(+), 34 deletions(-)
 delete mode 100644 package/glibc/2.18-svnr23787/glibc-0001-accept-make4.patch

Comments

Thomas Petazzoni April 7, 2014, 1:29 p.m. UTC | #1
Dear Gustavo Zacarias,

On Mon,  7 Apr 2014 10:04:39 -0300, Gustavo Zacarias wrote:
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  .../2.18-svnr23787/glibc-0001-accept-make4.patch   | 33 ----------------------
>  package/glibc/glibc.mk                             |  2 +-
>  2 files changed, 1 insertion(+), 34 deletions(-)
>  delete mode 100644 package/glibc/2.18-svnr23787/glibc-0001-accept-make4.patch

So we don't do like glibc where we support both 2.18 and 2.19 ? This is
really a question, maybe it makes sense to only support one version at
a time. In which case we could remove 2.18 from glibc.

Thomas
Gustavo Zacarias April 7, 2014, 1:36 p.m. UTC | #2
On 04/07/2014 10:29 AM, Thomas Petazzoni wrote:

> So we don't do like glibc where we support both 2.18 and 2.19 ? This is
> really a question, maybe it makes sense to only support one version at
> a time. In which case we could remove 2.18 from glibc.

My opinion is that we should just keep it as simple as possible.
If there's a special need for some architecture (like microblaze) let it
be so, but really unless we know there's some issue or exception i don't
think there's much value in keeping multiple versions, specially since
*glibc is backwards ABI compatible.
Regards.
Thomas Petazzoni April 7, 2014, 1:41 p.m. UTC | #3
Dear Gustavo Zacarias,

On Mon, 07 Apr 2014 10:36:43 -0300, Gustavo Zacarias wrote:

> > So we don't do like glibc where we support both 2.18 and 2.19 ? This is
> > really a question, maybe it makes sense to only support one version at
> > a time. In which case we could remove 2.18 from glibc.
> 
> My opinion is that we should just keep it as simple as possible.
> If there's a special need for some architecture (like microblaze) let it
> be so, but really unless we know there's some issue or exception i don't
> think there's much value in keeping multiple versions, specially since
> *glibc is backwards ABI compatible.

Fine with me. My impression so far was that for critical components
such as gcc/binutils/gdb/libc, we were keeping older versions a little
bit longer to give it some time to test the newer version before
forcing everyone to upgrade. Surely we need to continue to do this with
gcc, where most of the 4.x.0 versions are typically broken on at least
one architecture.

Thomas
Gustavo Zacarias April 8, 2014, 11:52 a.m. UTC | #4
On 04/07/2014 10:41 AM, Thomas Petazzoni wrote:

>> My opinion is that we should just keep it as simple as possible.
>> If there's a special need for some architecture (like microblaze) let it
>> be so, but really unless we know there's some issue or exception i don't
>> think there's much value in keeping multiple versions, specially since
>> *glibc is backwards ABI compatible.
> 
> Fine with me. My impression so far was that for critical components
> such as gcc/binutils/gdb/libc, we were keeping older versions a little
> bit longer to give it some time to test the newer version before
> forcing everyone to upgrade. Surely we need to continue to do this with
> gcc, where most of the 4.x.0 versions are typically broken on at least
> one architecture.

D'oh, eglibc 2.19 is broken for PowerPC SPE ABI.
So it seems we'll do two versions after all.
I'll send a revised patch shortly.
Regards.
Peter Korsgaard April 8, 2014, 12:19 p.m. UTC | #5
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

Hi,

 >> Fine with me. My impression so far was that for critical components
 >> such as gcc/binutils/gdb/libc, we were keeping older versions a little
 >> bit longer to give it some time to test the newer version before
 >> forcing everyone to upgrade. Surely we need to continue to do this with
 >> gcc, where most of the 4.x.0 versions are typically broken on at least
 >> one architecture.

 > D'oh, eglibc 2.19 is broken for PowerPC SPE ABI.
 > So it seems we'll do two versions after all.
 > I'll send a revised patch shortly.

Ok, thanks. It anyway seems like the safest option (and matches our
other toolchain-related packages)
diff mbox

Patch

diff --git a/package/glibc/2.18-svnr23787/glibc-0001-accept-make4.patch b/package/glibc/2.18-svnr23787/glibc-0001-accept-make4.patch
deleted file mode 100644
index 4f426f2..0000000
--- a/package/glibc/2.18-svnr23787/glibc-0001-accept-make4.patch
+++ /dev/null
@@ -1,33 +0,0 @@ 
-Backport upstream patch (28d708c44bc47b56f6551ff285f78edcf61c208a) to accept
-make-4.0 or newer.
-We patch both configure and configure.in files so if we ever have to run
-autoreconf in the glibc source, then the fix will be propagated properly.
-
-Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
-
-Index: glibc-2.18-svnr23787/libc/configure
-===================================================================
---- glibc-2.18-svnr23787.orig/libc/configure
-+++ glibc-2.18-svnr23787/libc/configure
-@@ -4772,7 +4772,7 @@ $as_echo_n "checking version of $MAKE...
-   ac_prog_version=`$MAKE --version 2>&1 | sed -n 's/^.*GNU Make[^0-9]*\([0-9][0-9.]*\).*$/\1/p'`
-   case $ac_prog_version in
-     '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
--    3.79* | 3.[89]*)
-+    3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
-        ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
-     *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
- 
-Index: glibc-2.18-svnr23787/libc/configure.in
-===================================================================
---- glibc-2.18-svnr23787.orig/libc/configure.in
-+++ glibc-2.18-svnr23787/libc/configure.in
-@@ -989,7 +989,7 @@ AC_CHECK_PROG_VER(CC, ${ac_tool_prefix}g
-   critic_missing="$critic_missing gcc")
- AC_CHECK_PROG_VER(MAKE, gnumake gmake make, --version,
-   [GNU Make[^0-9]*\([0-9][0-9.]*\)],
--  [3.79* | 3.[89]*], critic_missing="$critic_missing make")
-+  [3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*], critic_missing="$critic_missing make")
- 
- AC_CHECK_PROG_VER(MSGFMT, gnumsgfmt gmsgfmt msgfmt, --version,
-   [GNU gettext.* \([0-9]*\.[0-9.]*\)],
diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
index 6579f46..dbffdb7 100644
--- a/package/glibc/glibc.mk
+++ b/package/glibc/glibc.mk
@@ -16,7 +16,7 @@  GLIBC_SRC_SUBDIR = .
 endif
 else
 ifeq ($(BR2_TOOLCHAIN_BUILDROOT_EGLIBC),y)
-GLIBC_VERSION = 2.18-svnr23787
+GLIBC_VERSION = 2.19-svnr25243
 GLIBC_SITE = http://downloads.yoctoproject.org/releases/eglibc/
 GLIBC_SOURCE = eglibc-$(GLIBC_VERSION).tar.bz2
 GLIBC_SRC_SUBDIR = libc