Summary: | sys-libs/glibc-2.17 - rpcsvc/bootparam_prot.x: Value too large for defined data type | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | brho |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://sourceware.org/git/?p=glibc.git;a=commit;h=4c0fe6fe42ecf97c9f7f5a0921638560c89973a2 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 471102 | ||
Attachments: | glibc-no-change.log.gz |
Description
brho
2013-05-22 18:32:03 UTC
Created attachment 348938 [details]
glibc-no-change.log.gz
don't put -D_FILE_OFFSET_BITS into global CPPFLAGS. it doesn't make sense on a 64bit system like amd64. you've got a lot of ram. what if you mount tmpfs at /var/tmp/portage and build glibc ? does it work then ? Two comments: 1) After a fresh reboot (a crash/freeze, actually), the ebuild (on XFS) still needed its sunrpc Makefile changed to compile, and it installed completely. 2) With a tmpfs mounted at /var/tmp/portage, glibc emerged with no problem, and did not need the sunrpc Makefile change. i think this issue was fixed recently (for glibc-2.18) by: http://sourceware.org/git/?p=glibc.git;a=commit;h=4c0fe6fe42ecf97c9f7f5a0921638560c89973a2 you could try downloading that and putting it in /etc/portage/patches/sys-libs/glibc/ (you'll probably have to delete the ChangeLog hunks to get it to apply) That patch did the trick, thanks! (In reply to comment #5) since i'm fairly certain there are other broken packages, and cramming this one fix in won't help with the others, i'd prefer to just wait for the glibc-2.18 release to include things rather than add it to our glibc-2.17. here's a related thread: http://sourceware.org/ml/libc-alpha/2013-02/msg00575.html we probably will have to start some automated QA checks in our build if we want to stay on top of this since the issue affects all 32bit programs that call stat() on real filesystems (not pseudo ala procfs) and another link: http://blog.fmeh.org/2013/05/11/does-the-world-need-32-bit-inodes/ I agree. I've also run into issues with wine (fails during configure) and sandbox (fails when using FEATURES="sandbox" on glibc on my XFS, with the Value too large error). I'll post bugs for those too. Should I reference this one or some other central bug tracking the stat64? (In reply to comment #9) you should file one bug per package you find. i've started a new tracker (bug 471102), so include that in the blocker list when you do file things. Nice patch. However, it's not applied in the ebuild, so it isn't fixed. Needs reopening. (In reply to Roc Vallès from comment #11) read comment #6 |