Your message dated Sat, 4 Feb 2006 01:58:49 +1030 with message-id <[EMAIL PROTECTED]> and subject line libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries) has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
--- Begin Message --->From [EMAIL PROTECTED] Sun Apr 24 17:32:11 2005 Return-path: <[EMAIL PROTECTED]> Received: from kokytos.rz.ifi.lmu.de (kokytos.rz.informatik.uni-muenchen.de) [141.84.214.13] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DPrWF-0001As-00; Sun, 24 Apr 2005 17:32:11 -0700 Received: from nenya.lan (www.intermedia.lmu.de [141.84.8.49]) by kokytos.rz.informatik.uni-muenchen.de (Postfix) with ESMTP id 879B743668 for <[EMAIL PROTECTED]>; Mon, 25 Apr 2005 02:32:10 +0200 (CEST) Received: by nenya.lan (Postfix, from userid 1000) id 281CF59EC7; Mon, 25 Apr 2005 02:32:08 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Richard Atterer <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries) X-Mailer: reportbug 3.8 Date: Mon, 25 Apr 2005 02:32:08 +0200 Message-Id: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: mingw32 Version: 3.4.2.20040916.1-2 Severity: normal Hi, there is a problem with the binaries created by the cross-compiler; if they use the standard C++ library to access big files, seeking beyond 4GB does not appear to work. For a loong time, this was an upstream problem, but it was fixed with mingw.org's 3.4.0 release. Unfortunately, it still happens with binaries that I cross-compile from Debian. :-( The small program below prints the correct value "63" when compiled under Windows XP using mingw.org's binaries, but prints "-1 strerror: no error" (i.e. EOF) when cross-compiled. Working configurations on Windows were all the post-3.4.0 ones that I tried. Today, I specifically re-checked that the following results in working binaries: gcc-core-3.4.1-20040711-1.tar.gz gcc-g++-3.4.1-20040711-1.tar.gz w32api-2.5.tar.gz mingw-runtime-3.3.tar.gz gcc-core-3.4.2-20040916-1.tar.gz gcc-g++-3.4.2-20040916-1.tar.gz w32api-2.5.tar.gz (sorry, forgot upgrading that) mingw-runtime-3.7.tar.gz "g++ -v" prints this: Reading specs from C:/msys/1.0/mingw/bin/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) A fix for this would be very much appreciated!! - Compiling on Windows with MSYS is such a PITA! :-/ ---------------------------------------------------------------------- #include <fstream> #include <iostream> #include <string.h> using namespace std; int main() { fstream f("testfile", ios::binary|ios::in|ios::out|ios::trunc); #ifdef __MINGW32__ unsigned long long left = 0x100001000ULL; char buf[4096]; memset(buf, 0, 4096); f.write(buf, 4096); f.write("[EMAIL PROTECTED]", 10); // 64 aka '@' at 0x1004 f.write(buf, 4096 - 10); left -= 8192; while (left > 0) { f.write(buf, 4096); left -= 4096; } #else f.seekp(0x100001000ULL); #endif f.write("YADA?YADA!", 10); f.seekg(0x100001004ULL); cout << f.get() << endl; // Should print 63 for the '?' at 0x100001004 cout << "strerror: " << strerror(errno) << endl; } ---------------------------------------------------------------------- -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15) Versions of packages mingw32 depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii mingw32-binutils 2.15.94-20050118.1-1 Minimalist GNU win32 (cross) binut ii mingw32-runtime 3.7-1 Minimalist GNU win32 (cross) runti -- no debconf information
--- End Message ---
--- Begin Message --->From [EMAIL PROTECTED] Fri Feb 03 07:29:37 2006 Return-path: <[EMAIL PROTECTED]> Received: from ppp202-32.lns1.adl4.internode.on.net ([203.122.202.32] helo=hank.shelbyville.oz) by spohr.debian.org with esmtp (Exim 4.50) id 1F52sT-0005j4-CT for [EMAIL PROTECTED]; Fri, 03 Feb 2006 07:29:37 -0800 Received: from ron by hank.shelbyville.oz with local (Exim 4.60) (envelope-from <[EMAIL PROTECTED]>) id 1F52rj-0002f2-F3 for [EMAIL PROTECTED]; Sat, 04 Feb 2006 01:58:51 +1030 Date: Sat, 4 Feb 2006 01:58:49 +1030 To: [EMAIL PROTECTED] Subject: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries) Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060126 From: Ron <[EMAIL PROTECTED]> X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=0.0 required=4.0 tests=BAYES_20,RCVD_IN_SORBS autolearn=no version=2.60-bugs.debian.org_2005_01_02 Hi, I'm going to tentatively close this bug in the belief that it is fixed in the current unstable packages. The test case you posted, when run under wine, writes out a file of 4294971402 bytes -- and though the output there is still not correct: $ wine ./bigfile_test -1 strerror: Success Wine exited with a successful status The absence of any explicit "no space" error, and the size of the output file, gives me some confidence that the remaining errors may be related to wine. If it still craps out in a native environment, let me know and we'll have yet another look at what might be up. cheers, Ron
--- End Message ---
