lfs confusion

[John Hunter]

>>>>> "Andrew" == Andrew Dalke <adalke at mindspring.com> writes:

    Andrew> You might want to try doing a seek to a large int to see
    Andrew> what happens.

    Andrew> lfs_enabled = True try: fd.tell(sys.maxint * 3L) except
    Andrew> OverflowError: lfs_enabled = False

Do you mean fd.seek?

I get

>>> fd.tell(sys.maxint * 3L)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: tell() takes no arguments (1 given)

fd.seek works as advertised though.  On box 1 where fd.tell() returns
0L I can do fd.seek(sys.maxint * 3L).

On box2 "crcdocs" where fd.tell() returns 0, I get

>>> fd.seek(sys.maxint * 3L)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to int

I did manage to read and write a 4GB file on crcdocs using the script I
posted above.  Perhaps I don't understand what the "large" in large
file really means.  I assumed it was 2**31 approx equal 2GB.  Has the
default, non LFS limit, increased?

I did do the normal incantation with the CFLAGS when compiling python
for LFS on crcdocs.  

  982  CFLAGS='-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64' OPT="-g -O2 $CFLAGS"         ./configure
  983  make
  984  make install  


I now wonder if the there is a problem with my kernel or glibc.  

    crcdocs:~> ls /usr/lib/libglib-2.0.so.0*
    /usr/lib/libglib-2.0.so.0  /usr/lib/libglib-2.0.so.0.400.0

    crcdocs:~> uname -a
    Linux crcdocs.bsd.uchicago.edu 2.6.5-1.358 #1 Sat May 8 09:01:26 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux


I did create a 4GB file with a simple C++ program on crcdocs to test
whether my kernel/glibc supported large files.  Since I was able to
create the 4GB file successfully with this program, I assumed my
system was LFS enabled ).  Now I am not so sure this is the right test
for the system.

Do you have any suggestions or special tricks to test the system for
LFS, and do you do something different when compiling python for LFS?

JDH