PageDump: Known Problems

Preview: Page dump of Known Problems

Date: Mon, 26 Nov 2007 12:49:44 +0000
Mime-Version: 1.0 (Produced by PhpWiki 1.3.14)
Message-Id:
<1314-1196081384+0000-MinGW%3AKnown%20Problems@oldwiki.mingw.org>
Content-Type: application/x-phpwiki;
  pagename=Known%20Problems;
  flags="";
  author=EarnieBoyd;
  owner=PaulHarris;
  version=10;
  lastmodified=1196081384;
  created=1196081384;
  author_id=EarnieBoyd;
  markup=2;
  hits=20414;
  charset=iso-8859-1
Content-Transfer-Encoding: binary

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>