[Originally reported by Julien Lafon in http://xprint.mozdev.org/pipermail/xprint/2005-April/000460.html] The Xorg server and client code is currently not build with the neccesary flags to make it largefile aware, which may cause the one or other subtle issues at services such as libX11, Xaw and the Xserver code itself (Julien lafon's report was mainly about the Xserver but the issues affect other parts of X11, too).
Created attachment 2417 [details] [review] Prototype patch covering Linux and Solaris
torrey/herrb: Can you do the same change for MacOSX/Darwin and OpenBSD, please ?
(In reply to comment #2) > torrey/herrb: > Can you do the same change for MacOSX/Darwin and OpenBSD, please ? I'll have a deeper look later, but on *BSD (and afaict this includes Darwin) there's nothing to change. off_t is 64 bits long by default and no special calls are needed to open/read/write files above 2GB.
this patch only widens the types passed in to the system calls themselves, it does not make 64-bit off_t or fpos_t visible to consumers of the libc wrapper. are you sure that's what you intend?
(In reply to comment #4) > this patch only widens the types passed in to the system calls themselves, it > does not make 64-bit off_t or fpos_t visible to consumers of the libc wrapper. > are you sure that's what you intend? Yes as I do not need more for my own work and noone else cared about my original proposal to solve the issue similar how FreeBSD&co. solved the problem - which would be far far less work then adding another bunch of bloat to the libc wrapper. If anyone wants to deal with that issue then go ahead - my schedule is already too full and it's better for me not to take another burden only required by politics.
(In reply to comment #5) > Yes as I do not need more for my own work and noone else cared about my > original proposal to solve the issue similar how FreeBSD&co. solved the > problem - which would be far far less work then adding another bunch of bloat > to the libc wrapper. If anyone wants to deal with that issue then go ahead - > my schedule is already too full and it's better for me not to take another > burden only required by politics. i don't know which "original proposal" you're referring to, i don't see any concrete suggestions given in the thread linked in the initial bug report. neither was my comment politically motivated. i don't understand the hostility here. i was simply pointing out that if you expect large file access to work from the loadable modules, you will need to fix the libc wrapper. otherwise the libc wrapper's entrypoints will remain 32 bits wide for xf86size_t; they'll get promoted to 64 bits internally but the modules won't actually be able to use all 64 bits. since the initial bug report was concerning the postscript driver, and since you have stated before that you plan to make the Xprint drivers loadable, you may wish to solve this problem now rather than later.
(In reply to comment #6) > (In reply to comment #5) > > Yes as I do not need more for my own work and noone else cared about my > > original proposal to solve the issue similar how FreeBSD&co. solved the > > problem - which would be far far less work then adding another bunch of bloat > > to the libc wrapper. If anyone wants to deal with that issue then go ahead - > > my schedule is already too full and it's better for me not to take another > > burden only required by politics. > > i don't know which "original proposal" you're referring to, i don't see any > concrete suggestions given in the thread linked in the initial bug report. > neither was my comment politically motivated. i don't understand the > hostility here. That was not tought to be hostile, it's just a complaint that fixing this may end up in a huge pile of work if 100% compatibility to the current module ABI is required since we have to add transitional interfaces, add macros and all neccesary infratructure as it was done from Solaris 2.5.1-->Solaris2.6. And this needs to work properly on all platforms, even those which do not have largefile support. And it needs to be tested. So far this is a burden which I am not willing to take right now unless it becomes really neccesary. I would favor a solution similar to the way the *BSD OSs used here and avoid adding a giant pile of extra interfaces - just make clean cut and start with a cleaned-up interface scheme but that will never happen as this would break the holy(TM) module ABI. > i was simply pointing out that if you expect large file access to work from > the > loadable modules, you will need to fix the libc wrapper. otherwise the libc > wrapper's entrypoints will remain 32 bits wide for xf86size_t; they'll get > promoted to 64 bits internally but the modules won't actually be able to use > all 64 bits. AFAIK this is not true for the dlloader modules which can use libc directly. > since the initial bug report was concerning the postscript driver, and since > you have stated before that you plan to make the Xprint drivers loadable, > you may wish to solve this problem now rather than later. AFAIK the elfloader, a.out-loader&co. are going away post X11R7.0 and since the dlloader modules can access libc directly I do not think that this is neccesary. Just the Xserver code itself needs to be largefile aware (and all the libraries and client-side tools).
For the log: On my IRIX box "getconf" generates empty output for: -- snip -- % getconf LFS_CFLAGS % getconf LFS_LIBS -- snip -- so I assume IRIX is largefile aware without needing any extra flags (people in irc://freenode/#irix confirmed that info). CC:'ing Dan Mcnichol and Paul Anderson to look what's needed for AIX and HP/UX...
Created attachment 2523 [details] [review] Patch for 2005-04-23-trunk Same patch as attachment #2417 [details] [review] + Changelog diff...
Patch checked-in into Xorg trunk... /cvs/xorg/xc/ChangeLog,v <-- xc/ChangeLog new revision: 1.896; previous revision: 1.895 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. /cvs/xorg/xc/config/cf/linux.cf,v <-- xc/config/cf/linux.cf new revision: 1.26; previous revision: 1.25 /cvs/xorg/xc/config/cf/sun.cf,v <-- xc/config/cf/sun.cf new revision: 1.11; previous revision: 1.10 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. Mailing the commit message to xorg-commit@lists.freedesktop.org... ... leaving bug open for AIX and HP/UX...
i'm going to go ahead and claim it's fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.