FLTK logo

STR #1087

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 greg.ercolano
01:25 Nov 21, 2005
findlfs.csh
2k
 
 
#2 greg.ercolano
01:26 Nov 21, 2005
findlfs.out
7k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.