List of known problems that may cause you to lose your hair.
These may be problems with the compiler, DLL-based issues, Microsoft bugs, and platform problems. The problems may be bugs pending a fix, they may not be fixable, they may be inherent issues with the operating system design, etc.
The problems are grouped according to the configuration of a certain setup. Bugs change with releases and bug fixes, and often they don't, so don't forget to check older problems.
DW2 Exceptions - Confirmed
DW2 exceptions do not throw reliably across DLLs boundaries. This means you can't throw an exception from a function in one DLL, and catch it in a calling function that resides inside the .exe or another .DLL. Solution: Use SJLJ exceptions, until GCC 4 is supported under MinGW.
boost::serialization binary archive do not work properly.
I'm still working on it, but it looks like even the text_archive doesn't work. Crashes while trying to write a vector to an archive. More news as it comes to hand!
tellg() and text files - Confirmed
The basic reason is that text files have that extra carriage return character, and the MSVCRT library does some black magic to try and hide them from a C program. But, there is a bug in older MSVCRT libraries (the only one that can be freely distributed, and is commonly used by MinGW). The bug is in the seek code: program behaviour of seeking to anywhere except the start or the end of a text file is "undefined".
Thats fine, but the real trouble comes when you read a text file from start to finish and execute tellg() along the way - no seeking right? wrong! tellg() uses seeks to figure out where it is! So calling tellg() will not guarantee that the file cursor is in the same place as it was BEFORE you called tellg()!
Note that I've mostly mentioned problems with the C++ stream APIs. Because this is a fundamental problem underneath MinGW, in the platform libraries, the C API should also be affected.
Quote from a quote: Earnie Boyd's states "You can't seek and tell on a text mode file, it's not a bug, it's a defined feature".
- So there are a couple of workarounds
Date: Mon, 26 Nov 2007 19:39:05 +1300 From: Danny Smith <firstname.lastname@example.org> Reply-To: MinGW Devlopers Discussion List <email@example.com> Subject: Re: [MinGW-dvlpr] binutils-2.18.50 To: 'MinGW Devlopers Discussion List' <firstname.lastname@example.org> > Chris Sutcliff wrote: > Yep, like I mentioned previously, 2.18.50 built from FSF sources with > no modifications. If you build from CVS rather than from snapshot tarballs, you may run into problems with CRLF's in building info file for BFD. It works with some versions of makeinfo but not all. FWIW recent 2.18.50 snapshots have changde the handling of section alignment. Now, alignmemt is encoded in section header of object file, the same as done by MS tools. This may cause some backward compatibility issues with older libs that need 16 byte alignment for SSE2 objects. Please report any such problems to binutils list. danny