Re: test-fseek fails on W32

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04.04.2013 00:21, LRN wrote:
> On 04.04.2013 00:00, Eric Blake wrote:
>> On 04/01/2013 04:48 PM, Eric Blake wrote:
>>> On 04/01/2013 04:36 PM, LRN wrote:
>>>>>> Apparently, the MSVCRT implementation  of fseek() is
>>>>>> used.
>>>>>> 
>>>>>>> If not, then we should fix the m4 tests to filter out 
>>>>>>> the buggy W32 fseek and install the gnulib
>>>>>>> replacement.
>>>>>> 
>>>>>> I'm unsure of how they work.
>>>> 
>>>>> What does 'grep _FSEEK config.status' show?
>>>> $ grep _FSEEK config.status S["REPLACE_FSEEKO"]="0" 
>>>> S["REPLACE_FSEEK"]="0"
>>> 
>>> Well, apparently the m4 files don't think they need to replace 
>>> fseek...
>>> 
>>>> S["HAVE_FSEEKO"]="1" S["HAVE_DECL_FSEEKO"]="1" 
>>>> S["GNULIB_FSEEKO"]="1" S["GNULIB_FSEEK"]="1"
>>> 
>>> ...even though the gnulib modules are in use...
>>> 
>>>> D["HAVE_FSEEKO"]=" 1" D["HAVE_DECL_FSEEKO"]=" 1" 
>>>> D["GNULIB_TEST_FSEEK"]=" 1" D["GNULIB_TEST_FSEEKO"]=" 1" 
>>>> D["HAVE_RAW_DECL_FSEEKO"]=" 1"
>>>> 
>>>>> How about 'grep LSEEK_PIPE config.h'?
>>>> $ grep LSEEK_PIPE config.status D["LSEEK_PIPE_BROKEN"]=" 1"
>>> 
>>> ...and even though we know seek is broken on the platform.
>>> Looks like I'll have to figure out what went wrong; I'll
>>> probably have a patch in the next 24 hours or so.
> 
>> I'm still stumped on how to reproduce this; on latest gnulib.git
>>  installed in a Cygwin setup, I did:
> 
>> ./gnulib-tool --create-testdir --dir=testdir0 fseeko
> 
>> then in that directory did a configure with a cross compiler:
> 
>> ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin
> 
>> and the resulting build passed all tests.  Looking in 
>> config.status, I see:
> 
>> S["REPLACE_FSEEKO"]="0" S["REPLACE_FSEEK"]="1" 
>> S["HAVE_FSEEKO"]="0" S["HAVE_DECL_FSEEKO"]="0"
> 
>> which differs from your setup.  Maybe I should repeat my tests 
>> with mingw64 instead of the older mingw32?
> 
> H-m-m-m...if the problem is in the way gnulib detects whether it
> needs to replace fseek or not, then using mingw-w64 might give you
> different results, since mingw.org and mingw-w64 headers and crt
> differ significantly. I'll try doing the same thing you listed
> above on my msys+mingw-w64 installation. Any particular things in
> the output i should send back?
> 
> 
$ ./gnulib-tool --create-testdir --dir=testdir0 fseeko

$ cd testdir0

$ ./configure --prefix=/mingw --build=i686-w64-mingw32
- --host=i686-w64-mingw32

$ grep _FSEEK config.status
S["REPLACE_FSEEKO"]="0"
S["REPLACE_FSEEK"]="0"
S["HAVE_FSEEKO"]="1"
S["HAVE_DECL_FSEEKO"]="1"
S["GNULIB_FSEEKO"]="1"
S["GNULIB_FSEEK"]="1"
D["HAVE_FSEEKO"]=" 1"
D["HAVE_DECL_FSEEKO"]=" 1"
D["GNULIB_TEST_FSEEK"]=" 1"
D["GNULIB_TEST_FSEEKO"]=" 1"
D["HAVE_RAW_DECL_FSEEKO"]=" 1"

$ make check
...
FAIL: test-fseek.sh
...
FAIL: test-fseeko.sh
...

I'm using mingw-w64 svn r5685 and i686-w64-mingw32-gcc-4.8.0

Hacked up configure script to spew out some data.
Turns out,
WINDOWS_64_BIT_OFF_T=0, but gl_cv_var_stdin_large_offset=yes
mingw-w64 supports LFO, and gnulib doesn't think that it's appropriate
to override it.

I've looked at gl_STDIN_LARGE_OFFSET, and i'm not quite sure if it
tests anything other than cygwin.
So WINDOWS_64_BIT_OFF_T=0 is the thing that differs between mingw.org
and mingw-w64. AFAIU, mingw-w64 has 64-bit offset if
_FILE_OFFSET_BITS=64 is defined.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRXJifAAoJEOs4Jb6SI2CwA8sIAIIq7fG/K+gCSXnUOOsE2YVC
YJe4zdoSpH7Z5Pk0N9eC2A41u9Dvp1oAP5N+p1xtxY3p3XaiLfz8qqrp6jg9vF6y
8h49wJzajXHGphobHFOH7onEHg+7x0sbwfGCKsMX93QT0M9vocx78wIOVFcgSwSA
bN4AgRaRVzFPlIV5pAg9DmPDV6D9ZvhHSfMFwCeo/0JHJeEiShiR+RVixm78+iPn
GrJJ/TWl3njBmje1hBw1fkxRroPAgDSuLD/3zg2hFQec4/mqVsH2O0/c2k1Ahe2y
NNcg/2afLrm5EDCa+6bwB9L8L7qPSfEg7jfCuVo7xMwYzh9qI1UIUY1SALte+7c=
=8DCR
-----END PGP SIGNATURE-----