> Well, you did not describe exactly how it fails to compile for
> you. Assuming you got an error that something is not an integral type,
> then that is clearly an error in the code. You might want to
> investigate the error message you get more closely; please confirm
> that it refers to the return value of fgetpos.
Yes, apologies. I should have provided more details.
I'm using a stock Red Hat Linux 7.2, which has glibc 2.2.4 (Linux
kernel version 2.4.7).
With a Python built successfully from the 21-maintbranch without any
additional compiler flags indicating that I want large file support, I
get this when attempting to run the test_largefile test:
[chrism@kurtz tmp]$ python /usr/local/lib/python2.1/test/test_largefile.py
Traceback (most recent call last):
File "/usr/local/lib/python2.1/test/test_largefile.py", line 22, in ?
raise test_support.TestSkipped, \
test_support.TestSkipped: platform does not have largefile support
What's going on "under the hood" here is that a bit of code like this:
open('foo', 'w').seek(2147483649L)
.. raises an IOError 22, (invalid argument) out of the seek.
When I attempt to compile the code from the same branch using the
instructions for Solaris from
http://www.python.org/doc/current/lib/posix-large-files.html, it craps
out during a successive make:
gcc -c -g -O2 -I. -I./Include -DHAVE_CONFIG_H -o Objects/fileobject.o
Objects/fileobject.c
Objects/fileobject.c: In function `_portable_ftell':
Objects/fileobject.c:267: incompatible types in return
make: *** [Objects/fileobject.o] Error 1
[chrism@kurtz src]$
As a result, I am not able to compile successfully. (Note: FYI, the
same thing happens when following the slightly different current doc
instructions for Linux.)
So be it. With the patch you supplied earlier (and providing *either*
the "Solaris" or "Linux" largefile support flags to configure) I am able
to compile successfully and when invoking the resulting executable
against test_largefile.py, I get what looks like success, e.g.:
create large file via seek (may be sparse file) ...
2500000001L =?= 2500000001L ... yes
check file size with os.fstat
check file size with os.stat
2500000001L =?= 2500000001L ... yes
play around with seek() and read() with the built largefile
0L =?= 0 ... yes
..<and so on, successfully>..
So the question is this: is there reason to disbelieve test_largefile?
There seems to be some disbelief from Barry that your patch is "enough",
but it appears to work at least enough to fool test_largefile. ;-)
- C
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4