Yes, I noticed that my 2nd patch file did not work after I reloaded glibc and did svn update. Inspecting the configure file showed that it already had the changes and the patch file could not find the old patterns.
My sister's old laptop takes about 4 hrs 2 min 3 sec to build glibc.. Masochistic. I need to get my virtual box configured. Bob G On Sun, 2009-11-01 at 09:17 +0200, Mika Pesu wrote: > Hi, > > Thanks for testing and modifying the upstream patch. From the svn log i > noticed that René commited some binutils patch for glibc: > Commit by *rene* :: r*34767* /trunk/package/base/glibc/ > (any-cc-ok.patch.cross binutils-22.patch): > > * fixed glibc/configure for the new binutils version > > Look's like it's fixed now at svn. > > -Mika > > > Bob Gustafson kirjoitti: > > As one who has a little free time, I did some cut and paste from the git > > page you referenced. And then discovered that the git listing seems to > > add an additional line return and two leading spaces (or something like > > that) to each line listed. > > > > I did a manual edit of the two files and then successfully compiled > > glibc. This does not mean that my keystrokes are correct.. Looking at > > the upstream patch, I think I like your patch files better. The > > selection regex looks a little more consistent than the upstream patch. > > > > If anyone is interested, I have attached the two patch files. They could > > be dropped into directory package/base/glibc > > > > Bob G > > > > On Fri, 2009-10-30 at 20:21 +0200, Mika Pesu wrote: > > > >> Hi list, > >> > >> The recent update of binutils broke glibc, because glibc fails to > >> recognize ld --version that comes from binutils. > >> > >> With some git browsing i found the upstream commit to fix it, here's the > >> link: > >> http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0549ce8ec1f66a41c59815e50dd48ffd74fabb52;hp=6dfeb5245bca9f2ef94815ed9a7b979a9e0be744 > >> > >> I havent yet tryed the upstream patch, but if someone with free time > >> could test it. > >> > >> Attached is my local patch for glibc, but i guess upstream fix could be > >> better one. > >> > >> -Mika > >> plain text document attachment (binutils_recognize_for_glibc.patch) > >> diff --git a/configure b/configure > >> index 7555891..fdfbd2d 100755 > >> --- a/configure > >> +++ b/configure > >> @@ -4839,7 +4839,7 @@ $as_echo_n "checking version of $AS... " >&6; } > >> ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* > >> \([0-9]*\.[0-9.]*\).*$/\1/p'` > >> case $ac_prog_version in > >> '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; > >> - 2.1[3-9]*) > >> + 2.1[3-9]*|[2-9].[2-9]*) > >> ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; > >> *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; > >> > >> @@ -4902,7 +4902,7 @@ $as_echo_n "checking version of $LD... " >&6; } > >> ac_prog_version=`$LD --version 2>&1 | sed -n 's/^.*GNU ld.* > >> \([0-9][0-9]*\.[0-9.]*\).*$/\1/p'` > >> case $ac_prog_version in > >> '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; > >> - 2.1[3-9]*) > >> + 2.1[3-9]*|[2-9].[2-9]*) > >> ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; > >> *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; > >> > >> diff --git a/configure.in b/configure.in > >> index d54e952..05c396a 100644 > >> --- a/configure.in > >> +++ b/configure.in > >> @@ -897,10 +897,10 @@ AC_SUBST(MIG)dnl Needed by sysdeps/mach/configure.in > >> # Accept binutils 2.13 or newer. > >> AC_CHECK_PROG_VER(AS, $AS, --version, > >> [GNU assembler.* \([0-9]*\.[0-9.]*\)], > >> - [2.1[3-9]*], AS=: critic_missing="$critic_missing as") > >> + [2.1[3-9]*|[2-9].[2-9]*], AS=: > >> critic_missing="$critic_missing as") > >> AC_CHECK_PROG_VER(LD, $LD, --version, > >> [GNU ld.* \([0-9][0-9]*\.[0-9.]*\)], > >> - [2.1[3-9]*], LD=: critic_missing="$critic_missing ld") > >> + [2.1[3-9]*|[2-9].[2-9]*], LD=: > >> critic_missing="$critic_missing ld") > >> > >> # We need the physical current working directory. We cannot use the > >> # "pwd -P" shell builtin since that's not portable. Instead we try to > >> > >> > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [email protected] with a subject of: unsubscribe t2
