| [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1087
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 2 - Specific to an operating system |
Subsystem: | Build Files |
Summary: | Suggest adding -D_FILE_OFFSET_BITS=64 gcc flag for linux builds |
Version: | 1.1-current |
Created By: | greg.ercolano |
Assigned To: | mike |
Fix Version: | 1.1-current (SVN: v4702) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | greg.ercolano 01:51 Nov 20, 2005 |
| I was encountering problems with FLTK file browsers being unable to browse an SGI's 64 bit file system from 32 bit linux clients (redhat9 & Fedora Core 3) that were solved by adding the gcc flag "-D_FILE_OFFSET_BITS=64" to the FLTK build.
CAUSE ----- The cause of the problem was scandir() returning "Value too large.." errors, due to the 64 bit quantities being unparsable by the default 32 bit oriented data structures in scandir()/opendir()/readdir().
SOLUTION -------- Recompiling FLTK with the above gcc flag fixes the problem; the browser now can navigate the SGI dirs successfully from the 32bit linux machine.
More info on this gcc flag here: http://www.suse.de/~aj/linux_lfs.html ..see the "Using LFS" section.
TESTS DONE ---------- Using fltk-1.1.x r4650 (svn updated just now), I verified building w/out the flag causes the file_chooser binary to fail to browse the SGI, and rebuilding FLTK /with/ the flag enabled works OK. Same behavior running the binaries on both redhat9 and Fedora Core 3 clients.
Tested both the negative and positive cases with 1.1.x and 1.1.6-utf8, each compiled on a redhat9 system.
RECOMMENDATION -------------- If not a default, should probably be at least a 'recommended' 'configure' option for linux builds. Best part is: no code changes needed ;) | |
|
#2 | mike 06:26 Nov 20, 2005 |
| FWIW, there is a larger issue with this - large file support doesn't always come "for free". Specifically, it alters the sizes and signatures of some core types, so we'll need to do an API review before adding large file support... | |
|
#3 | greg.ercolano 10:39 Nov 20, 2005 |
| Agreed.
Some interesting links:
List of 64 bit functions: http://www.unix.org/version2/whatsnew/lfs20mar.html#3.1.1 (eg. opendir, readdir, fstat, etc..)
List of 64 bit data types: http://www.unix.org/version2/whatsnew/lfs20mar.html#3.1.2
I'm about to run to a meeting, but I might be able to cobble together a giant find/grep combo to print all fltk source that references these functions/data types. Might at least be a start for review. | |
|
#4 | greg.ercolano 01:25 Nov 21, 2005 |
| Attached find:
1) findlfs.csh -- greps fltk code for lfs funcs + data types 2) findlfs.out -- test run of above on 1.1.x current
The csh program is not perfect, but is maybe a good starting point for identifying areas of code to check.
Script ran/tested on redhat9; it might have linux specific find/egrep syntax. (eg. might not run as well on OSX or IRIX) | |
|
#5 | matt 01:41 Nov 21, 2005 |
| Thanks Greg for testing this out. There seems to be no data type in the header files, except for our private version of dirent. It looks like a good sign to me that changing this flag will not change the footprint. I'll leave the decission to Mike though. | |
|
#7 | greg.ercolano 02:16 Nov 21, 2005 |
| Thanks Matthais.
I think in general you should be OK cause you're already running on 64 bit hardware (fltk's been on IRIX64 for a while now).
But I imagine any assumptions about eg. a 'size_t' being a uint instead of ulong would be bad; that might fly fine on a 64bit OS, but fail on 32 bit OS with 64bit extensions, such as what we have here.
Beware: you'd think you'd get a demotion warning from 'g++ -Wall', but you don't. This on redhat9:
-------------------------------------------------------------------- % cat foo.cxx int main() { long x = 123123123; int y = x; // looses precision.. x++; y++; } % g++ -Wall foo.cxx -o foo % <-- ..no warning with -Wall % g++ -Wall -pedantic -W foo.cxx -o foo % <-- ..nothing, even with -W (-Wextra) --------------------------------------------------------------------
I remember being shocked when I had such a bug, and only the SGI 6.5 compiler caught it.
In fact, I can't find the g++ flag that enables this warning. Mike, I'll bet you know ;) | |
|
#8 | greg.ercolano 02:55 Nov 21, 2005 |
| Meh -- in my foo.cxx, I meant the 'int' to be 'short' to show the problem. The lack of errors is the same, though on redhat9/32bit OS:
------------------------------------------------------------------ % cat foo.cxx int main() { long x = 0x11112222; short y = x; // precision loss long->short x++; y++; } % g++ -Wall foo.cxx -o foo % <-- no error with -Wall % g++ -Wall -W foo.cxx -o foo % <-- even with -W (-Wextra) ------------------------------------------------------------------
..whereas on SGI and Microsoft Windows it complains:
------------------------------------------------------------------ # CC -fullwarn foo.cxx -o foo "foo.cxx", line 4: remark(1506): implicit conversion from "long" to "short": rounding, sign extension, or loss of accuracy may result short y = x; ^ ------------------------------------------------------------------ Z:\tmp>cl /TP /Wall /Wp64 /nologo foo.cxx foo.cxx foo.cxx(4) : warning C4244: 'initializing' : conversion from 'long' to 'short', possible loss of data ------------------------------------------------------------------ | |
|
#9 | mike 16:40 Dec 13, 2005 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |