| Summary: | sys-libs/glibc-2.18-r1 install error on stage3-armv7a_hardfp-20140112 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Steve Arnold <nerdboy> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | major | CC: | arm |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | ARM | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info
emerge -pqv env emerge --info end of build log |
||
|
Description
Steve Arnold
2014-02-04 04:56:05 UTC
I've got a box here that compiled -r1 on 1/24/2014
Installed versions: 2.18-r1(2.2)^s(11:53:47 01/24/14)(-debug -gd -hardened -multilib -nscd -profile -selinux -suid -systemtap -vanilla CROSSCOMPILE_OPTS="-headers-only")
With no issue, so the change on 1/25 -
Mike Frysinger <vapier@gentoo.org> glibc-2.18-r1.ebuild:
Add fix for armv4 (non thumb) and for alpha/tls code from upstream.
May be suspect?
the only new patch is this: http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.18/00_all_0034-ARM-Fix-clone-build-for-ARMv4.patch and it should produce the same code before & after for armv7 devices that said, it's working for me: - download stage3-armv7a_hardfp-20140112.tar.bz2 - add "sys-libs/glibc ~arm" to package.keywords - update sys-libs/glibc to 2.18 tested on an EXYNOS5 (armv7) CPU w/neon support and linux-3.4 kernel. (In reply to SpanKY from comment #3) > that said, it's working for me: > - download stage3-armv7a_hardfp-20140112.tar.bz2 > - add "sys-libs/glibc ~arm" to package.keywords > - update sys-libs/glibc to 2.18 > > tested on an EXYNOS5 (armv7) CPU w/neon support and linux-3.4 kernel. Ditto, tested on a 3.8 and 3.4 kernel and can't reproduce here either, I just did some digging for Steve into what might have caused the issue since he ran into it on 2 different boards. I replaced the previous suspect SSD in the trimslice and redid the install from the same stage3 and portage snapshot, then masked glibc-2.18 and installed a few packages (plus quite a few deps) using the desktop profile. Then tried the glibc upgrade and got the same error :( Attachments follow... Created attachment 369984 [details]
emerge --info
output of `emerge --info '=sys-libs/glibc-2.18-r1::gentoo'`
Created attachment 369986 [details]
emerge -pqv
output of `emerge -pqv '=sys-libs/glibc-2.18-r1::gentoo'`
Created attachment 369988 [details]
env
ebuild environment file
Created attachment 369990 [details]
emerge --info
output of `emerge --info '=sys-libs/glibc-2.18-r1::gentoo'`
Created attachment 369992 [details] end of build log See the full log here: http://www.gentoogeek.org/files/glibc-log.txt go into the directory and run the failing command yourself. if it still fails, run it through gdb and figure out what insn exactly is failing. you didn't say what cpu exactly you're using other than it's an armv7a. FYI, If you want to try against, I just pushed out an updated version of those stages: <mirror>/experimental/arm/hardened/stage3-armv7a_hardfp-hardened-20140627.tar.bz2 However, I doubt it will make a difference for this bug. (In reply to Anthony Basile from comment #12) > FYI, If you want to try against, I just pushed out an updated version of > those stages: That should read "if you want to try again" Sorry for the extra email. (In reply to SpanKY from comment #11) > go into the directory and run the failing command yourself. if it still > fails, run it through gdb and figure out what insn exactly is failing. > > you didn't say what cpu exactly you're using other than it's an armv7a. Actually he mentioned 2 different boards that he seemed to run into the issue. Trimslice is a tegra2 with no neon unit BBB is an omap (4?) and does have a neon unit... But based on his emerge --info it doesn't seem that either one has neon enabled, so that shouldn't matter. |