The following problems were observed on a fresh Gentoo 2015Q3 installation: AMD64 multilib stage3/portage from 20150730 with emerge --sync on 20150803 The install volume is a 2TB XFS partition created with mkfs.xfs defaults. make.conf: ABI_X86="64 32" Errors when trying to emerge xorg-x11 or xorg-server: libX11 (Value too large for defined data type) Errors when trying to emerge (firefox/seamonkey): nspr (Value too large for defined data type) nss (Value too large for defined data type) This error may be related to XFS. The 32-bit compile path may require this: #define _FILE_OFFSET_BITS 64 The workaround is to use PORTAGE_TMPDIR="/ram" on a tmpfs /ram mount. You can override it on the command line with the following to manually emerge the problem packages and then emerge the larger packages: PORTAGE_TMPDIR="/ram" emerge libX11 PORTAGE_TMPDIR="/ram" emerge nspr PORTAGE_TMPDIR="/ram" emerge nss THEN, this error crops up with nss: plarena.h: No such file or directory This error may be related to 32-bit pkgconfig. Try this as a workaround: ABI_X86="64" PORTAGE_TMPDIR="/ram" emerge nspr nss Then xorg-x11 and Mozilla (firefox/seamonkey) should emerge without further errors but be sure you don't continue to use PORTAGE_TMPDIR="/ram" unless you have more than 4GB available in the tmpfs for the Mozilla compile(s). Reproducible: Always Steps to Reproduce: 1. Fresh install of stage3 + portage tree on large XFS volume. 2. Edit /etc/portage/repos.conf; emerge --sync 3. emerge xorg-x11 OR xorg-server 4. emerge firefox OR seamonkey Actual Results: Multiple failures due to errors in the compile: Value too large for defined data type Header files not found Expected Results: No failures in the compile. This is an informational bug report. I know full multilib is a WORK IN PROGRESS. I only wish to have this documented so the next person who gets these errors will be able to resolve them quickly and move along with their Gentoo install. A workaround is provided in the Description but ideally this should be fixed at the ebuild level so that no one needs to reference this bug report ever again. emerge --info is default from stage3+portage+emerge --sync, with the default make.conf that has only this added: ABI_X86="64 32"
libX11 failure is: src/util/makekeys.c (Value too large for defined data type) nspr failure is: ../../../config/./nsinstall (Value too large for defined data type) nss failure looks like this: Creating ../../dist/public/nss directory creation race: ../.. nsinstall: cannot mkdir -p ../..: (Value too large for defined data type)
Possibly related to <a href="/show_bug.cgi?id=499070">#499070:</a> When I was getting the failure on libX11, I actually did patch the libX11 ebuild to see what the error was in those "couldn't open" messages and the error was "Value too large for defined data type", so please reference #499070 for the actual error output from my attempt to do the libX11 emerge.
This is probably a duplicate of bug 550502
But I don't see any reports about nss and nspr. It make sense to file separate bug reports and make them block the tracker bug 471102
Alexander Tsoy: Thanks for those links, they really helped me understand this. I did some more digging too, after more packages failed to emerge, like all of Qt4 and bits of xorg-x11. Overriding with ABI_X86="64" to get them to emerge is not a proper fix because I do need 32-bit support to run legacy applications. It looks like XFS is enabling 64-bit inodes by default for volumes >1TB. I'll go scrape the volume and start over and force mkfs.xfs to use 32-bit inodes. I don't need 390 million inodes anyway, so I can set imaxpct=1 too and get back 80GB that would have otherwise been reserved for inodes. According to df -i, the dying 1TB drive the 2TB is replacing has used <2% of the inodes, so I should re-consider just exactly how many inodes I need to use. I think this bug can be closed. It's a short between my chair and my keyboard, due to my lack of understanding of the XFS defaults for >1TB volumes.
After more reading of the xfs.org docs, it looks like I can use 32-bit inodes and increase the inode size to 512 bytes to allow up to 2TB volume size. This will allow XFS to keep the inodes near the data and avoid excessive seeking to save wear and tear on the drive and, with any luck, allow the legacy 32-bit applications to work without modification or special environment variables. I'll keep this bug open for a little while until I try this approach and give some feedback later as to whether or not this actually did fix the problems.
Increasing the inode size on XFS solved the problem. I'm closing this bug as it was obviously an end user error on my part.
