Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Unable to update gcc or glibc with XFS (solved)
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
slowdive
n00b
n00b


Joined: 01 May 2005
Posts: 41

PostPosted: Wed May 22, 2013 6:43 pm    Post subject: Unable to update gcc or glibc with XFS (solved) Reply with quote

On a fresh install, I could not build gcc or glibc. I was able to build binutils. I'm using XFS (this is important later).

After installing an amd64 desktop multilib profile, I tried to install the latest version of gcc (4.7.3, up from 4.6.3):
Code:
emerge -avq gcc


I got emerge errors for gcc during gcc's stage2 such as:
Quote:
configure: error: unsupported system, cannot find sizeof (omp_lock_t)
make[2]: *** [configure-stage1-target-libgomp] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.3/work/build'


I removed openmp from the USE keywords, and it failed a little farther on (I forget the exact error, and lost the build log). From what I remember, it was related to a mismatch of sizes, perhaps a 32 bit thing.

I tried installing a few emul-linux-*, since I thought it might be multilib related. That didn't help. I also tried setting the ABI_X86 value to "64 32" in make.conf, since the first hit from google talked about multilib issues recently. That didn't help.

Eventually, I tried to update all the packages in 'system':
Code:
USE="-ldap -sasl -mysql" emerge -uDavNq --keep-going system
I turned off those USEs to avoid some circular dependencies, and also to cut down on the list of things to build. Gcc and glibc are part of this list, and they failed, while everything else continued.

I stumbled on http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Value-too-large-for-defined-data-type, which made me think the reinstall of coreutils would help. It did, but only after I deleted the gcc working directory in /var/tmp/portage/sys-devel/gcc-4.7.3. I guess whatever the problem file was, it was being cached in the build directory and needed to be freshly rebuilt. Either that, or possibly there was another program in 'system' that helped. Not sure on this.

glibc still failed to build, even after removing the working directory. Here's the first error I get:

Quote:
CPP='x86_64-pc-linux-gnu-gcc -m32 -E -x c-header' /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen -Y ../scripts -c rpcsvc/rstat.x -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/xrstat.T
rpcsvc/bootparam_prot.x: Value too large for defined data type
make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/xbootparam_prot.stmp] Error 1
make[2]: *** Waiting for unfinished jobs....


Setting MAKEOPTS="-j1" to avoid concurrent errors, the first error is:

Quote:
CPP='x86_64-pc-linux-gnu-gcc -m32 -E -x c-header' /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/xbootparam_prot.T
rpcsvc/bootparam_prot.x: Value too large for defined data type


Different compilation, but the same root cause. I can slim down the command given to:
Code:
/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpcgen -c rpcsvc/rstat.x


It actually doesn't matter what file is used as the -c input to cross-rpcgen. So I looked at the code building cross-rpcgen, and noticed it didn't have -D_FILE_OFFSET_BITS=64. I hacked up a bash script to rebuild cross-rpcgen with the FILE_OFFSET_BITS set (just did a search/replace on "-m32 " to replace it with "-m32 -D_FILE_OFFSET_BITS=64 ", and the new cross-rpcgen was able to open files without getting the "Value too large" error.

I manually extracted the ebuild and changed the sunrpc Makefile to add in the FILE_OFFSET_BITS:
Code:
cd /usr/portage/sys-libs/glibc/
ebuild glibc-2.17.ebuild unpack
vi /var/tmp/portage/sys-libs/glibc-2.17/work/glibc-2.17/sunrpc/Makefile
ebuild glibc-2.17.ebuild compile


I edited the Makefile like so:
Code:

-sunrpc-CPPFLAGS = -D_RPC_THREAD_SAFE_
+sunrpc-CPPFLAGS = -D_RPC_THREAD_SAFE_ -D_FILE_OFFSET_BITS=64


This compiled correctly, getting past the previous errors. However, when I tried to install:
Code:
ebuild glibc-2.17.ebuild install

The install fails:
Quote:

if test -r /var/tmp/portage/sys-libs/glibc-2.17/image//usr/include/gnu/stubs-32.h && cmp -s /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/stubs.h /var/tmp/portage/sys-libs/glibc-2.17/image//usr/include/gnu/stubs-32.h; \
then echo 'stubs.h unchanged'; \
else /usr/bin/install -c -m 644 /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/stubs.h /var/tmp/portage/sys-libs/glibc-2.17/image//usr/include/gnu/stubs-32.h; fi
rm -f /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/stubs.h
/var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln /var/tmp/portage/sys-libs/glibc-2.17/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/symlink.list
/var/tmp/portage/sys-libs/glibc-2.17/image//lib32/libc.so.6: invalid destination: Value too large for defined data type
/var/tmp/portage/sys-libs/glibc-2.17/image//lib32/ld-linux.so.2: invalid destination: Value too large for defined data type
make[1]: *** [install-symbolic-link] Error 255
make[1]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.17/work/glibc-2.17'
make: *** [install] Error 2
emake failed


My guess is that everything in glibc that is built 32 bit also needs the -D_FILE_OFFSET_BITS=64. After hunting around for -m32, I found /var/tmp/portage/sys-libs/glibc-2.17/temp/environment, which had a CFLAG_x86 variable with -m32. I put this in my make.conf:
Code:
CFLAGS_x86="-m32 -D_FILE_OFFSET_BITS=64"
and rebuilt glibc from scratch. That didn't work, there were numerous errors early on such as:
Quote:
../include/sys/stat.h:16:1: warning: asm declaration ignored due to conflict with previous rename [-Wpragmas]
So I guess I can't just turn on -D_FILE_OFFSET_BITS.

Anyway, I filed a bug: https://bugs.gentoo.org/show_bug.cgi?id=471024 If anyone has any ideas, I'd love to hear them. One part of the problem may be that I'm running XFS. Here's an older bug related to GCC, XFS, and the Value too large: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44116. That bug was fixed, but perhaps this is just a bug that is more likely to be exposed on XFS than ext3/4.

Update: after a full reboot (actually, the machine froze and spammed the ethernet port - possibly another issue), I was able to install the ebuild after hacking the sunrpc Makefile. The cross-rpcgen still needed to be built with -D_FILE_OFFSET_BITS=64. A fresh emerge was still insufficient.

Update 2: Mounting a tmpfs at /var/tmp/portage allowed glibc to emerge without any changes.

Update 3: The issue was that glibc's helper programs were not able to handle 64 bit inodes, (XFS was mounted with inode64). This has been fixed upstream in 2.18 in patch http://sourceware.org/git/?p=glibc.git;a=commit;h=4c0fe6fe42ecf97c9f7f5a0921638560c89973a2. It's possible that the problems I was having with gcc were also related to the inode64 issue, and I was just lucky with the allocation of specific inode numbers.
Back to top
View user's profile Send private message
gordonp
Tux's lil' helper
Tux's lil' helper


Joined: 23 May 2005
Posts: 100

PostPosted: Mon May 27, 2013 3:47 pm    Post subject: Reply with quote

Wow slowdive!

You are a lot more-knowledgeable (and persistent) than I am. But I am getting the same GCC error you refer to
Code:
configure: error: unsupported system, cannot find sizeof (omp_lock_t)
make[2]: *** [configure-stage1-target-libgomp] Error 1

with my otherwise-up-to-date, XFS-enabled Gentoo Vserver-host, and stable gcc-4.6.3.

Removing /var/tmp/portage/sys-devel/gcc/ and setting -J1 did not help me.

"Me too" :-(
Back to top
View user's profile Send private message
slowdive
n00b
n00b


Joined: 01 May 2005
Posts: 41

PostPosted: Mon May 27, 2013 4:04 pm    Post subject: Reply with quote

With GCC, my guess is I got lucky when I rm'd gcc's directory from /var/tmp/portage. If the problem is related to 64 bit inodes, then there might be some element of chance to whether or not an inode that is too big is assigned to a particular file (if i'm understanding this properly).

To troubleshoot, can you run "mount" and see if "inode64" is in the mount options for whatever partition has /var/tmp/portage? If so, save a copy of the gcc's failed build log (might submit it later), and try to build gcc on another file system. If you have a decent amount of RAM, mount a tmpfs at /var/tmp/portage and rebuild (this is what I did to glibc)

Code:

mount -t tmpfs tmpfs /var/tmp/portage

That should do the trick. If you don't have a lot of RAM, then perhaps you can connect a USB stick and mount it there - something with another file system. Alternatively, you can remount XFS with inode32. I hear that works nowadays.

Anyway, if gcc builds without the problem, please submit a bug with the failed build log and reference https://bugs.gentoo.org/show_bug.cgi?id=471102. That's a tracker bug one of the dev's made in response to my glibc bug, where we all can track down the packages that don't handle large inodes.

Actually, even if gcc doesn't build on the non-XFS partition, I'd still submit a bug report! I didn't at the time since I thought it was related to my faulty install (mine was a fresh amd64).
Back to top
View user's profile Send private message
dacoo
n00b
n00b


Joined: 08 Jun 2013
Posts: 2

PostPosted: Sat Jun 08, 2013 10:35 am    Post subject: Reply with quote

same diagnostic here,
XFS on a 2Tera+ volume,

the tmpfs mount allowed me to pass over the problem
TY
Back to top
View user's profile Send private message
rvalles
Tux's lil' helper
Tux's lil' helper


Joined: 19 Feb 2003
Posts: 121

PostPosted: Sat Jun 08, 2013 11:39 am    Post subject: Reply with quote

Closed (patch works) but not really fixed (patch not being applied in portage's ebuild):
https://bugs.gentoo.org/show_bug.cgi?id=471024

That's why we're still having trouble today. Apparently I cannot reopen the bug.
Back to top
View user's profile Send private message
gongloo
n00b
n00b


Joined: 01 Nov 2002
Posts: 19
Location: Boston, MA, USA

PostPosted: Wed Dec 11, 2013 8:13 am    Post subject: Reply with quote

I was able to get this working with glibc by using the tmpfs method, but I didn't quite have enough ram for a tmpfs large enough to build gcc, so I tried with FEATURES="-sandbox -usersandbox" and that did the trick.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum