MinGW - View Source: Known Problems

List of known problems that may cause you to lose your hair.

With

* [Automated MinGW Installer | ProblemsMinGWInstaller]

----

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.

!!! 2006-07-04

!! Configuration

 * binutils-2.16.91-20060119-1
 * mingw-runtime-3.9
 * gcc-core-3.4.5-20060117-1
 * w32api-3.7
 * gcc-g++-3.4.5-20060117-1

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

Quote from Danny Smith's email of Thu, 06 Jul 2006,  "Re: [Mingw-users] DW2 EH works "sometimes" ?" (I can't find it in the SourceForge mailing archives)

    Yes.  I've just built gcc 4.2 with DW2 EH and libgcc and libstdc++ built as dll's and your testcase works just fine




!! boost::serialization

boost::serialization binary archive do not work properly.<br>[http://boost.org/libs/serialization/doc/index.html

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

If you open a text file with std::ifstream as a text file (not as a binary file with std::ios::binary), then you must not use tellg() to check the position of the cursor.  Or ftell().

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.

http://sourceforge.net/mailarchive/message.php?msg_id=15755711
http://sourceforge.net/mailarchive/message.php?msg_id=15760637

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:

 # Don't open files in text-mode.  http://sourceforge.net/mailarchive/message.php?msg_id=17327648
 # Don't call tellg() and continue to read afterwards.
 # Somehow upgrade to a newer MSVCRT. http://sourceforge.net/mailarchive/message.php?msg_id=15760637
 # Help MinGW and write the file IO libraries so we don't rely on MSVCRT in this regard.  Ask mailing list for details if this is even possible.

!! Binutils-2.18.50

<verbatim>
    Date: Mon, 26 Nov 2007 19:39:05 +1300
    From: Danny Smith <dannysmith@clear.net.nz>
Reply-To: MinGW Devlopers Discussion List <mingw-dvlpr@lists.sourceforge.net>
 Subject: Re: [MinGW-dvlpr] binutils-2.18.50
      To: 'MinGW Devlopers Discussion List' <mingw-dvlpr@lists.sourceforge.net>


>

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