Red Hat Bugzilla – Bug 500487
fallocate64 is missing
Last modified: 2018-04-11 08:48:51 EDT
On 32 bit platforms, programs that #define _FILE_OFFSET_BITS 64 and call the fallocate() function get an "undefined reference to fallocate64" linker error.
Example program attached.
Created attachment 343666 [details]
gives a linker error on 32 bit on glibc-2.9.90-22
I was just wondering also about the need to #include <linux/falloc.h>
Since this is not a syscall anymore, shouldn't <linux/falloc.h>
be mirrored in <sys/falloc.h> and one should now be including that?
linker error still happens on glibc-2.10.1-2.i686
I also note that the new version (3.21) of the linux man pages describe the glibc interface as I would expect:
I.E. there should be no need to include <linux/falloc.h>,
but this is still the case with glibc-2.10.1-2
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
This bug seems to be solved in glibc:
it makes impossible to build some packages under fedora 11 (like amule adunanza, a patched amule version for fastweb users, widely used in Italy. I'm trying to build an rpm for it). Could the fix be backported to fedora 11?
Unfortunately no, this can't be backported. The symbol is exported as @@GLIBC_2.11 symbol, F11 has only glibc 2.10. If we add a single GLIBC_2.11 symbol, we'd have to add them all, which means at least wait until glibc 2.11 is released (in 4-5 months approximately).
Thanks for the update Gio!
Jakub, what about the interface as described here:
I.E. that is more standard as there is no need to include <linux/falloc.h>, and
fallocate() returns -1 on error rather than the errno?
I presume it's too late to change now and so the manpage will need to be changed.
FWIW, I have added an fallocate call to xfs_io in xfsprogs upstream; for now I'lll probably just condition it on not needing fallocate64, so i586 for example just won't get it.
Could it be added as @@GLIBC_2.10.1?
(In reply to comment #9)
> Could it be added as @@GLIBC_2.10.1?
No. The version nunber is 2.11. That's not something that can be moved around. Only full releases are allowed to change the ABI and 2.11 is the one this symbol got introduced.
Just use F12.
I presume since this is closed, the answer to the 6 month old question in comment #7 is that the non standard interface will not change. Fair enough.
I'll update gnulib and the man pages to match.