Bug#306210: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries)
On Tue, Oct 11, 2005 at 01:13:53AM +0930, Ron wrote: Could you confirm if this is still a problem with the current release or not? Yes - unfortunately it is! The program I posted earlier in this bug writes just a little less than 4GB of data into the file (on NTFS), then fails with No space left on device. I cross-compiled this program today in a freshly updated sid chroot. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#306210: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries)
Hi, Could you confirm if this is still a problem with the current release or not? thanks! Ron On Mon, Apr 25, 2005 at 11:30:05AM +0930, Ron wrote: On Mon, Apr 25, 2005 at 02:32:08AM +0200, Richard Atterer wrote: 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. Do we need to enable LFS explicitly somehow? I usually rely on upstream to set (most of) the defaults for this sort of thing, but recently had to add -sjlj explicitly to stay on track with them. I don't see anything obvious in the information provided. Do you know what was 'fixed' in the msys release? I'm currently waiting on a new binutils release to fix some known issues, if you can track down the cause of this, I can update likewise, but I don't have time to chase this myself in the immediate near future. thanks, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306210: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries)
On Mon, Apr 25, 2005 at 11:30:05AM +0930, Ron wrote: Do we need to enable LFS explicitly somehow? To my knowledge, no. This was supposed to be fixed for all architectures with GCC 3.4 (there were other problems for GCC 3.0 to 3.3). I guess the relevant code in libstdc++ just #defines _FILE_OFFSET_BITS=64, things might go wrong if your glibc-cross headers somehow don't react to this. I don't see anything obvious in the information provided. Do you know what was 'fixed' in the msys release? No, sorry. :-| The problem was still there in their very first GCC 3.4 release candidate, but they fixed it after I contacted them. I'm currently waiting on a new binutils release to fix some known issues, if you can track down the cause of this, I can update likewise, but I don't have time to chase this myself in the immediate near future. OK. Are you going to ask upstream about this? Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#306210: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries)
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 = 0x11000ULL;
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(0x11000ULL);
#endif
f.write(YADA?YADA!, 10);
f.seekg(0x11004ULL);
cout f.get() endl; // Should print 63 for the '?' at 0x11004
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-binutils2.15.94-20050118.1-1 Minimalist GNU win32 (cross) binut
ii mingw32-runtime 3.7-1Minimalist GNU win32 (cross) runti
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306210: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries)
On Mon, Apr 25, 2005 at 02:32:08AM +0200, Richard Atterer wrote: 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. Do we need to enable LFS explicitly somehow? I usually rely on upstream to set (most of) the defaults for this sort of thing, but recently had to add -sjlj explicitly to stay on track with them. I don't see anything obvious in the information provided. Do you know what was 'fixed' in the msys release? I'm currently waiting on a new binutils release to fix some known issues, if you can track down the cause of this, I can update likewise, but I don't have time to chase this myself in the immediate near future. thanks, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
