Bug#306210: acknowledged by developer (libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries))
On Wed, Feb 08, 2006 at 05:21:38PM +0100, Richard Atterer wrote: Some more info: I went through the whole libstdc++ build process before coming up with my patch. Would you like to hear the most amusing irony about this that I've seen to date? While poking about to fix some different problems, I just happened to notice that upstream DID apply your patch to the current release. I guess you should update the other reports to concur that it in fact does not work for you either... ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306210: acknowledged by developer (libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries))
On Sat, Feb 25, 2006 at 01:04:32AM +1030, Ron wrote: Would you like to hear the most amusing irony about this that I've seen to date? While poking about to fix some different problems, I just happened to notice that upstream DID apply your patch to the current release. Whoa, interesting! I tested your mingw32 3.4.5.20060117.1-1 package without success - was this built using the current release you refer to?? If yes, I will have to check once more where the problem is. I guess you should update the other reports to concur that it in fact does not work for you either... ;-) My patch works with mingw32 3.4.2.20040916.1-2 - does the timestamp in the version number refer to the GCC release? A lot can happen in 1.5 years. :-| Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#306210: acknowledged by developer (libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries))
On Wed, Feb 08, 2006 at 05:21:38PM +0100, Richard Atterer wrote:
Some more info:
I went through the whole libstdc++ build process before coming up with my
patch. IIRC, some configure tests are not executed when cross-compiling,
which results in something like __USE_LARGEFILE64 and friends (or similar,
I don't remember the details) not being set up correctly.
Obviously you can't test for runtime features on the host when you
are cross compiling. That isn't an easy problem to solve if there
is no static test that would be equivalent.
And libstdc++ itself building ok is no guarantee that any of its
functions will actually work when called. If you don't call them
you will never know.
It's true that the native build does not define _GLIBCXX_USE_LFS. ISTR
the reason I chose it was that with it, all the dependent defines like
__USE_LARGEFILE64 were set up by the libstdc++ header files.
I'm guessing you are talking about _LARGEFILE{,64}_SOURCE -- which seems
to have some mentions in a couple of places, but grep doesn't seem to
find it in much code...
Unfortunately, it's been a while and I will have to go through the build
process again to find an alternative solution.
I don't think going through the build process is going to help you.
You are going to need to use the Source. Since _GLIBCXX_USE_LFS isn't
used in very many places either -- and if you look at them, you'll
probably see that in most places, the required code for billware is
entirely absent and there are no magic guards marking all the places
it might need to be.
So your mission, should you choose to accept it, would seem to be:
a) Identify all the code paths affected by this change,
b) Write portable test cases that exercise them to prove your changes
and guard against regressions (if they don't already exist in the
gcc test suite).
c) Fix the code for mingw (and/or gcc ;) that breaks the test cases.
If you were to prod upstream with a report on that work you might
have a bit more luck at catching their attention to incorporate it.
Reproducible results are much better than a blank claim that something
is fully tested. And if you leave half that work for someone else
to do, then you'll have to be patient while they find time to do the
rest. But every little bit helps if it builds a better picture for
the next player.
I don't think there is a magic bullet here which will let us just
turn this on with the flip of a switch. I don't know why your
native billware works, perhaps that version has better posix
emulation or something, because at a quick glance, it looks to me
like there is glue missing if you need to call the functions that
Danny pointed at. Someone will have to implement (most of the
rest of) that. It looks like someone made a start, then left it
disabled behind _GLIBCXX_USE_LFS __MINGW__.
hth get you a bit further.
best,
Ron
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306210: acknowledged by developer (libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries))
reopen 306210 thanks On Fri, Feb 03, 2006 at 07:48:53AM -0800, Debian Bug Tracking System wrote: I'm going to tentatively close this bug in the belief that it is fixed in the current unstable packages. I'm sorry, I've just tested it and it still doesn't work. :-/ I compiled my example program using mingw 3.4.5.20060117.1-1, mingw32-binutils 2.16.91-20060119.1-1 and mingw32-runtime 3.9-3, then ran it on an NTFS partition on a Windows XP system. The program wrote 4294963200 bytes of data (that's 0xF000), then exited with: -1 strerror: no space left on device Did you actually apply my patch? Unfortunately, upstream seems to ignore my bug report (no followups on http://sourceforge.net/tracker/index.php?func=detailaid=1235337group_id=2435atid=102435), maybe you could prod them about it? BTW, this bug should probably be reassigned to mingw and not libstdc++, because according to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22388#c3 the respective bug is in mingw-specific modifications to the standard libstdc++. 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 I don't think wine is a good test platform for this kind of thing. :-/ Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 0x888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯
Bug#306210: acknowledged by developer (libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries))
forwarded 306210 http://sourceforge.net/tracker/index.php?func=detailaid=1235337group_id=2435atid=102435 thanks On Tue, Feb 07, 2006 at 11:49:26AM +0100, Richard Atterer wrote: I'm sorry, I've just tested it and it still doesn't work. :-/ I compiled my example program using mingw 3.4.5.20060117.1-1, mingw32-binutils 2.16.91-20060119.1-1 and mingw32-runtime 3.9-3, then ran it on an NTFS partition on a Windows XP system. The program wrote 4294963200 bytes of data (that's 0xF000), then exited with: -1 strerror: no space left on device Gack. Ok, I figured wine was right with either one or the other. The file (size) written must have been a figment of its imagination. Did you actually apply my patch? No. You also filed it upstream, so I deferred it to whatever their solution would be. I was running a bunch of test cases on the new release, including yours -- which wasn't clear whether it succeeded or failed. I figured you'd get the memo and if need be, we'd reopen, lather, repeat, as required. Like this ;-) Unfortunately, upstream seems to ignore my bug report (no followups on http://sourceforge.net/tracker/index.php?func=detailaid=1235337group_id=2435atid=102435), maybe you could prod them about it? I've got a couple of other bugs on the roll there for w32api, I'll see what I can learn. BTW, this bug should probably be reassigned to mingw and not libstdc++, because according to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22388#c3 the respective bug is in mingw-specific modifications to the standard libstdc++. How many places did you spray this report? Looking at this one you just answered your own question (and mine) from above: (thanks ;-) --- Comment #1 From Danny Smith 2005-07-09 23:11 [reply] --- mingw runtime does not have struct stat64 or fstat64(), so this define is not correct. In fact the native build of libstdc++ fails the _GLIBCXX_USE_LFS configure test. (mingwt does have struct _stati64 and _fstati64() which would work in __basic_filechar::showmanyc) Danny Which doesn't look to me like ignoring it at all. He simply claims it is wrong. Which fairly simply convinces me not to apply it. Did you ask him about what the correct solution might be? Proof by Works For Me is not sufficient here. I think the onus to learn more is back on you in the light of this... 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 I don't think wine is a good test platform for this kind of thing. :-/ No. But it is all I have in front of me. And its been a reasonable bet that things which _do_ work properly on it, also work ok elsewhere. In this case, it seems (postmortem) to have more or less done the right thing on both sides of the fence (written a large file to linux, and failed to read it in the (PE) process). I needed someone to cross check that to put the result I had in perspective. Sorry its still not fixed -- but I think you are going to have to look a bit harder for a more suitable fix. I'm pretty sure Danny might know about some code paths you haven't chosen to look down yet, so if he has doubts, I certainly share them. To convince me, you'll have to convince him. I'm going to mark this one forwarded, Danny appears to have taken responsibility for it and left it open, so I can only assume he plans to fix it properly some day when he has time. The best way to accelerate that is probably ask what needs to be done and promptly do it. Prodding busy people doesn't make them go faster. But giving them what they need, when they need it, clearly does. Thanks! Ron (who'll probably otherwise keep pinging you on the status of new uploads while wine is indecisive ...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
