[arch-dev-public] [signoff] glibc-2.13 toolchain rebuild
Here goes the toolchain rebuild for glibc-2.13: glibc-2.13-1 - major upstream release - Fedora 14 uses a pre-release glibc from this branch so it should be a fairly safe update... linux-api-headers-2.6.37-1 - version bump gcc-4.5.2-5 - just a rebuild (I will probably bump to a newer snapshot in the coming weeks as lots of backports are moving onto that branch lately with progress towards gcc-4.6) binutils-2.21-3 - just a rebuild (not much of interest has landed on the 2.21 branch since the last build) valgrind-3.6.0-2 - patch and rebuild for glibc-2.13 - not particularly tested here so reports of success/failures would be good... Now for the fun part! Some x86_64 users (depending on their cpu) will notice sound issues with mp3s of certain bitrates in flash when using Adobe's pre-release x86_64 flash plugin. This is because somebody at Adobe does not know to not use memcpy with source and destination overlapping. I will not be disabling the optimisation that causes this issue because it does result in significant speed increases in memcpy/memmove and because the issue is in an unsupported, pre-release, binary blob. For work arounds see: https://bugzilla.redhat.com/show_bug.cgi?id=638477 Allan
On Tue, Jan 18, 2011 at 7:55 PM, Allan McRae <allan@archlinux.org> wrote:
Here goes the toolchain rebuild for glibc-2.13:
glibc-2.13-1 - major upstream release - Fedora 14 uses a pre-release glibc from this branch so it should be a fairly safe update...
linux-api-headers-2.6.37-1 - version bump
gcc-4.5.2-5 - just a rebuild (I will probably bump to a newer snapshot in the coming weeks as lots of backports are moving onto that branch lately with progress towards gcc-4.6)
binutils-2.21-3 - just a rebuild (not much of interest has landed on the 2.21 branch since the last build)
valgrind-3.6.0-2 - patch and rebuild for glibc-2.13 - not particularly tested here so reports of success/failures would be good...
Working good here for our old friend pacman. Signoff valgrind/glibc/gcc and probably everything for x86_64. But we did expose a problem via valgrind in glibc gettext (it doesn't occur if you do something like `pacman -Q glibc` because there are no gettext calls), what fun. Looks like both strcasecmp_l and strncasecmp_l have something odd with them. -Dan dmcgee@galway ~/projects/pacman (master) $ valgrind pacman -V ==806== Memcheck, a memory error detector ==806== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==806== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==806== Command: pacman -V ==806== .--. Pacman v3.4.2-242-gdd26-dirty - libalpm v5.0.2 / _.-' .-. .-. .-. Copyright (C) 2006-2011 Pacman Development Team \ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet '--' ==806== Conditional jump or move depends on uninitialised value(s) ==806== at 0x52D70DB: strcasecmp_l (in /lib/libc-2.13.so) ==806== by 0x528AC59: bsearch (in /lib/libc-2.13.so) ==806== by 0x52868F6: ??? (in /lib/libc-2.13.so) ==806== by 0x5284997: ??? (in /lib/libc-2.13.so) ==806== by 0x528418D: ??? (in /lib/libc-2.13.so) ==806== by 0x407B6E: main (pacman.c:226) ==806== ==806== Use of uninitialised value of size 8 ==806== at 0x52D9214: strcasecmp_l (in /lib/libc-2.13.so) ==806== by 0x528AC59: bsearch (in /lib/libc-2.13.so) ==806== by 0x52868F6: ??? (in /lib/libc-2.13.so) ==806== by 0x5284997: ??? (in /lib/libc-2.13.so) ==806== by 0x528418D: ??? (in /lib/libc-2.13.so) ==806== by 0x407B6E: main (pacman.c:226) ==806== ==806== Use of uninitialised value of size 8 ==806== at 0x52D9218: strcasecmp_l (in /lib/libc-2.13.so) ==806== by 0x528AC59: bsearch (in /lib/libc-2.13.so) ==806== by 0x52868F6: ??? (in /lib/libc-2.13.so) ==806== by 0x5284997: ??? (in /lib/libc-2.13.so) ==806== by 0x528418D: ??? (in /lib/libc-2.13.so) ==806== by 0x407B6E: main (pacman.c:226) ==806== This program may be freely redistributed under the terms of the GNU General Public License. ==806== ==806== HEAP SUMMARY: ==806== in use at exit: 0 bytes in 0 blocks ==806== total heap usage: 58 allocs, 58 frees, 14,585 bytes allocated ==806== ==806== All heap blocks were freed -- no leaks are possible ==806== ==806== For counts of detected and suppressed errors, rerun with: -v ==806== Use --track-origins=yes to see where uninitialised values come from ==806== ERROR SUMMARY: 15 errors from 3 contexts (suppressed: 7 from 7) :: Synchronizing package databases... ==1386== Conditional jump or move depends on uninitialised value(s) ==1386== at 0x52D4331: strncasecmp_l (in /lib/libc-2.13.so) ==1386== by 0x53348E6: ??? (in /lib/libc-2.13.so) ==1386== by 0x5334F6A: ??? (in /lib/libc-2.13.so) ==1386== by 0x6EAC9E2: pthread_once (in /lib/libpthread-2.13.so) ==1386== by 0x5313D9D: ??? (in /lib/libc-2.13.so) ==1386== by 0x5313F71: getaddrinfo (in /lib/libc-2.13.so) ==1386== by 0x55B76D3: fetch_connect (in /usr/lib/libfetch.so) ==1386== by 0x55BE070: http_request (in /usr/lib/libfetch.so) ==1386== by 0x55BE77B: fetchStatHTTP (in /usr/lib/libfetch.so) ==1386== by 0x4E395FE: download_internal.5534 (in /home/dmcgee/projects/pacman/lib/libalpm/.libs/libalpm.so.5.0.2) ==1386== by 0x4E39FE9: _alpm_download_single_file (in /home/dmcgee/projects/pacman/lib/libalpm/.libs/libalpm.so.5.0.2) ==1386== by 0x4E3A2EB: alpm_db_update (in /home/dmcgee/projects/pacman/lib/libalpm/.libs/libalpm.so.5.0.2)
On 20/01/11 03:13, Dan McGee wrote:
On Tue, Jan 18, 2011 at 7:55 PM, Allan McRae<allan@archlinux.org> wrote:
Here goes the toolchain rebuild for glibc-2.13:
glibc-2.13-1 - major upstream release - Fedora 14 uses a pre-release glibc from this branch so it should be a fairly safe update...
linux-api-headers-2.6.37-1 - version bump
gcc-4.5.2-5 - just a rebuild (I will probably bump to a newer snapshot in the coming weeks as lots of backports are moving onto that branch lately with progress towards gcc-4.6)
binutils-2.21-3 - just a rebuild (not much of interest has landed on the 2.21 branch since the last build)
valgrind-3.6.0-2 - patch and rebuild for glibc-2.13 - not particularly tested here so reports of success/failures would be good...
Working good here for our old friend pacman. Signoff valgrind/glibc/gcc and probably everything for x86_64. But we did expose a problem via valgrind in glibc gettext (it doesn't occur if you do something like `pacman -Q glibc` because there are no gettext calls), what fun. Looks like both strcasecmp_l and strncasecmp_l have something odd with them.
This looks like: http://bugs.kde.org/show_bug.cgi?id=256600 Nothing to worry about. I will pull the patch from valgrind SVN at some stage. Allan
On 20/01/11 21:25, Allan McRae wrote:
On 20/01/11 03:13, Dan McGee wrote:
On Tue, Jan 18, 2011 at 7:55 PM, Allan McRae<allan@archlinux.org> wrote:
Here goes the toolchain rebuild for glibc-2.13:
glibc-2.13-1 - major upstream release - Fedora 14 uses a pre-release glibc from this branch so it should be a fairly safe update...
linux-api-headers-2.6.37-1 - version bump
gcc-4.5.2-5 - just a rebuild (I will probably bump to a newer snapshot in the coming weeks as lots of backports are moving onto that branch lately with progress towards gcc-4.6)
binutils-2.21-3 - just a rebuild (not much of interest has landed on the 2.21 branch since the last build)
valgrind-3.6.0-2 - patch and rebuild for glibc-2.13 - not particularly tested here so reports of success/failures would be good...
Working good here for our old friend pacman. Signoff valgrind/glibc/gcc and probably everything for x86_64. But we did expose a problem via valgrind in glibc gettext (it doesn't occur if you do something like `pacman -Q glibc` because there are no gettext calls), what fun. Looks like both strcasecmp_l and strncasecmp_l have something odd with them.
This looks like: http://bugs.kde.org/show_bug.cgi?id=256600
Nothing to worry about. I will pull the patch from valgrind SVN at some stage.
And valgrind-3.6.0-3 is in [testing] with a fix for this. Allan
On Fri, Jan 21, 2011 at 12:42 AM, Allan McRae <allan@archlinux.org> wrote:
On 20/01/11 21:25, Allan McRae wrote:
On 20/01/11 03:13, Dan McGee wrote:
On Tue, Jan 18, 2011 at 7:55 PM, Allan McRae<allan@archlinux.org> wrote:
Here goes the toolchain rebuild for glibc-2.13:
glibc-2.13-1 - major upstream release - Fedora 14 uses a pre-release glibc from this branch so it should be a fairly safe update...
linux-api-headers-2.6.37-1 - version bump
gcc-4.5.2-5 - just a rebuild (I will probably bump to a newer snapshot in the coming weeks as lots of backports are moving onto that branch lately with progress towards gcc-4.6)
binutils-2.21-3 - just a rebuild (not much of interest has landed on the 2.21 branch since the last build)
valgrind-3.6.0-2 - patch and rebuild for glibc-2.13 - not particularly tested here so reports of success/failures would be good...
Working good here for our old friend pacman. Signoff valgrind/glibc/gcc and probably everything for x86_64. But we did expose a problem via valgrind in glibc gettext (it doesn't occur if you do something like `pacman -Q glibc` because there are no gettext calls), what fun. Looks like both strcasecmp_l and strncasecmp_l have something odd with them.
This looks like: http://bugs.kde.org/show_bug.cgi?id=256600
Nothing to worry about. I will pull the patch from valgrind SVN at some stage.
And valgrind-3.6.0-3 is in [testing] with a fix for this.
Appears to be working now and suppressing this stuff, thanks. -Dan
[2011-01-19 11:55:32 +1000] Allan McRae:
Here goes the toolchain rebuild for glibc-2.13:
glibc-2.13-1 - major upstream release - Fedora 14 uses a pre-release glibc from this branch so it should be a fairly safe update...
linux-api-headers-2.6.37-1 - version bump
gcc-4.5.2-5 - just a rebuild (I will probably bump to a newer snapshot in the coming weeks as lots of backports are moving onto that branch lately with progress towards gcc-4.6)
binutils-2.21-3 - just a rebuild (not much of interest has landed on the 2.21 branch since the last build)
signoff i686 for all these (not valgrind; i don't do much with it) -- Gaetan
participants (3)
-
Allan McRae
-
Dan McGee
-
Gaetan Bisson