Glibc with bare gentoo patchset is unusable on arm (a lot of runtime errors like "assertion m == cmt failed"). With few patches from openembedded it works well and seems to be stable. Links to patches: http://www.openembedded.org/repo/org.openembedded.dev/packages/glibc/glibc-cvs/arm-longlong.patch http://www.openembedded.org/repo/org.openembedded.dev/packages/glibc/glibc-cvs/arm-memcpy.patch http://www.openembedded.org/repo/org.openembedded.dev/packages/glibc/glibc-cvs/dl-cache-libcmp.patch They need a bit monotonous modification to apply to glibc-2.6.1
Created attachment 132798 [details, diff] arm-longlong.patch
Created attachment 132799 [details, diff] arm-memcpy.patch In fact is in't needed to run glibc, but it gives some performance boost.
Created attachment 132801 [details, diff] dl-cache-libcmp.patch Main patch. It fixes cmp assertion failure
arm-longlong patch seems to breake compatibility with oreviosliy compiled packages, because it changes size of longlong it can be resolved by recompiling entry system =)
patches works fine at least we have no assertion m == cmt failed so this patches needed for arm =)
*** Bug 203813 has been marked as a duplicate of this bug. ***
Comment on attachment 132798 [details, diff] arm-longlong.patch i'm not adding something that isnt from upstream and breaks ABI
can you explain how/when you see the assert message ? that change affects everyone, not just arm. i'm running glibc-2.7 on arm right now and havent seen any assert messages.
i'm running arm with eabi on hx4700 assertion happens very rare but it breaks compilation =) I'm can only see this message during compilation while running glibc-2.6 with gentoo patchset
glibc-2.7 works fine w gentoo patchest 1.6 + arm-memcpy.patch + dl-cache-libcmp.patch hx4700 ~ # /lib/libc-2.7.so GNU C Library stable release version 2.7, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.2.3 (Gentoo 4.2.3 p1.0). Compiled on a Linux >>2.6.21-hh19<< system on 2008-03-07. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo patchset 1.6.1 GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>.
mit-frame-pointer -MT cfbtileoddC.lo -MD -MP -MF .deps/cfbtileoddC.Tpo -c -o cfbtileoddC.lo cfbtileoddC.c Inconsistency detected by ld.so: ../elf/dl-sysdep.c: 456: _dl_important_hwcaps: Assertion `m == cnt' failed! assertion message that i get during emergeing xorg-server
(In reply to comment #11) > mit-frame-pointer -MT cfbtileoddC.lo -MD -MP -MF .deps/cfbtileoddC.Tpo -c -o > cfbtileoddC.lo cfbtileoddC.c > Inconsistency detected by ld.so: ../elf/dl-sysdep.c: 456: _dl_important_hwcaps: > Assertion `m == cnt' failed! > > assertion message that i get during emergeing xorg-server > Deleting existing files for mesa module ... Inconsistency detected by ld.so: ../elf/dl-sysdep.c: 456: _dl_important_hwcaps: Assertion `m == cnt' failed! DONE another assertion message =)
Is this still needed? wfm on armv5tel-softfloat-linux-gnueabi...
glibc-2.8 is now stable...still getting this stuff, or can we close this bug?
Still random assertions with glibc 2.8 and 2.9 with swap on armv5te-softfloat-linux-gnueabi.
@arm: Can anyone reproduce this? If it were a widespread issue, I'm sure we would have seen more bugs by now.
I couldn't reproduce it on armv7a. Unfortunately I don't have armv5tel to test.
I can reproduce this issue on XScale-PXA270 rev 7 (v51) (Sharp Akita) gcc-4.3.2-r4 glibc-2.8_p20080602-r1 -march=iwmmxt The issue is not reproducible with -march=armv5te instead of iwmmxt.
some analysis at http://article.gmane.org/gmane.linux.ports.arm.general/11795
(In reply to comment #18) > I can reproduce this issue on > XScale-PXA270 rev 7 (v51) (Sharp Akita) > gcc-4.3.2-r4 > glibc-2.8_p20080602-r1 > -march=iwmmxt > > The issue is not reproducible with -march=armv5te instead of iwmmxt. > Ah, that would explain why i don't get it, i don't have an iwmmxt capable processor... Enrico, according to your report, its not related to the userland, so its something hard to fix, then. Definitely those patches attached here that mean recompiling the system aren't going to be applied..
