Bug 500487

Summary: fallocate64 is missing
Product: [Fedora] Fedora Reporter: Pádraig Brady <p>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 11CC: drepper, esandeen, gio.grifis, jakub, kzak, mcepl, mcepl, pbonzini
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-23 00:58:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
gives a linker error on 32 bit on glibc-2.9.90-22 none

Description Pádraig Brady 2009-05-12 21:44:46 UTC
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.

Comment 1 Pádraig Brady 2009-05-12 21:47:18 UTC
Created attachment 343666 [details]
gives a linker error on 32 bit on glibc-2.9.90-22

Comment 2 Pádraig Brady 2009-05-27 21:31:57 UTC
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?

Comment 3 Pádraig Brady 2009-05-28 13:08:22 UTC
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:
http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html
I.E. there should be no need to include <linux/falloc.h>,
but this is still the case with glibc-2.10.1-2

Comment 4 Bug Zapper 2009-06-09 15:43:08 UTC
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Giovanni Masucci 2009-06-11 20:21:37 UTC
This bug seems to be solved in glibc:
http://repo.or.cz/w/glibc.git?a=commit;h=1f3615a1c97a030bca59f728f998947f852679b9
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?

Comment 6 Jakub Jelinek 2009-06-11 20:40:37 UTC
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).

Comment 7 Pádraig Brady 2009-06-12 09:11:27 UTC
Thanks for the update Gio!

Jakub, what about the interface as described here:
http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html

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.

Comment 8 Eric Sandeen 2009-06-15 17:38:45 UTC
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.

Comment 9 Paolo Bonzini 2009-07-26 14:50:05 UTC
Could it be added as @@GLIBC_2.10.1?

Comment 10 Ulrich Drepper 2009-11-23 00:58:40 UTC
(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.

Comment 11 Pádraig Brady 2009-11-23 09:41:07 UTC
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.