tracker for packages which still use 32bit filesystem interfaces (stat/read/lseek/etc... instead of stat64/read64/lseek64/etc...). feel free to ask general questions here, but specific bug reports should be in dedicated bugs (and listing them as blockers to this).
this has always been a problem. typically though people only notice when they try to do with large files (like working with files over 2GiB in size). but the stat() issue is going to be affecting people even more as filesystems (like NFS and XFS) start to deploy 64bit inodes. now if you stat() a file on disk that happens to have a 64bit inode, you'll get an error (EOVERFLOW).
for many apps, the fix is simple: build with -D_FILE_OFFSET_BITS=64. this will redefine funcs/types/structs from the 32bit version to the 64bit version (e.g. off_t will automatically turn into off64_t, stat() will become stat64(), etc...).
if you're building a library that exports off_t as part of its ABI (in a struct or func return/arg), this change will most likely change things. in that case, you should consider defining:
then you can internally change the code to call stat64() and use off64_t without changing the sizes of the 32bit types (e.g. off_t is still off_t).
this will require more work though to make things portable (like checking if stat64() even exists) as not all C libraries/operating systems have taken this approach.
some random background links:
I hit this with ~amd64 current sys-devel/gcc:4.7 and :4.8 (running glibc-2.17)
(In reply to Michael Weber from comment #1)
i have no idea what this means. you really need to provide actual details.
it's come up again:
this time i've posted a patch. i'll probably include it in glibc-2.20 when it comes out to see what goes boom ...
Is it possible that the glusterfs network file system is always returning
inode numbers larger than 2**32?
Trying to rebuild gcc where /var/tmp/portage is a glusterfs share
from an XFS file system on the file server:
configure: updating cache ./config.cache
* ../../sandbox-2.6/libsandbox/libsandbox.c:check_syscall():879: failure (Value too large for defined data type):
configure: error: unsupported system, cannot find sizeof (omp_lock_t)
make: *** [configure-stage1-target-libgomp] Error 1
Seems to be similar to the forum discussion
This smells like a stat problem, since the server side logs
many of these:
[server-rpc-fops.c:1739:server_stat_cbk] 0-porttmp-server: 2676750: STAT
(null) (adbcef83-56c6-4caf-b974-7b14796bde8c) ==>
(No such file or directory)
Something that might also be related is that
emerge --buildpkg y <some-package> fails, e.g. sys-libs/tmezone-data
fails with a glusterfs file system for /var/tmp/portage, but
emerge --buildpkg n <some-package> does not.
>>> Completed installing timezone-data-2013d into /var/tmp/portage/sys-libs
strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R
.GCC.command.line -R .note.gnu.gold-version
ecompressdir: bzip2 -9 /usr/share/man
tar: ./usr/share/zoneinfo/posix: file changed as we read it
tar: ./usr/share/zoneinfo/right/Asia: file changed as we read it
tar: ./usr: file changed as we read it
This also generates STAT (null) errors on the server side
The first bit looks similar to bug #502202.
if you're using autotools, you can use one of these macros in your configure.ac:
the latter is a super set of the former. which is appropriate depends entirely on the package in question. the manual has more details:
(In reply to SpanKY from comment #6)
to clarify, the latter will enable _GNU_SOURCE which implicitly enables LFS support. however, it does not turn on transparent LFS, so packages still have to use alternative function names like fseeko.
if you use AC_SYS_LARGEFILE, then the build will automatically enable transparent LFS which means you don't have to do anything else.
if you wish to use both, make sure you call AC_SYS_LARGEFILE after AC_USE_SYSTEM_EXTENSIONS otherwise you'll get warnings when you run autotools.