-----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-----