This document presents a categorized list of questions, and answers, relating to the MinGW.OSDN software distributions, and their use.
The answer to each question may be revealed, immediately below it, by clicking on the question itself. In the case of questions for which the answer is already visible, a further click on the question will dismiss the view of the answer.
Created by Colin Peters,
and released to the public domain,
the original MinGW — or “Minimalist GNU for
Windows” — was a system of import libraries,
header files, and supporting “glue” code,
to facilitate the use of Microsoft’s
CRTDLL.DLL
— and
later MSVCRT.DLL
— as
the primary run‑time support for a native MS‑Windows port
of the GNU Compiler Collection (GCC), and its supporting utilities,
(which, in turn, were originally provided by Jan‑Jaap van der Heijden).
Today, MinGW has become synonymous with the entire system comprising these GNU tools, a significantly extended derivative of Colin’s original run‑time system, together with complementary import libraries, and headers, to facilitate access to the MS‑Windows API, a further collection of complementary libraries, and utilities, and even the native MS‑Windows environment in which they run, providing a complete Open Source programming tool set which is suitable for the development of native MS‑Windows applications, with no implicit dependency on any 3rd‑party C‑Runtime DLL.
Originated by Steve Chamberlain, in 1995, like MinGW, Cygwin is a system which aims to make (primarily) GNU tools available on the MS‑Windows platform; however, the two systems adopt entirely different  methodologies to achieve this objective.
Both systems are based on GNU tooling,
and both use the GNU Compiler Collection (GCC) as the means
of production for their respective application suites.
Since GNU is fundamentally a POSIX system,
both MinGW and Cygwin tools exhibit a POSIX feel;
however, whereas MinGW strives to minimize its POSIX influence,
using the MS‑Windows API directly, 
and thus,
MinGW applications may be classified as native 
MS‑Windows applications,
Cygwin has a much loftier objective ... it aims to provide a complete
emulation of the entire  POSIX.1 API!
This emulation is encapsulated within a single cygwin1.dll
shared object library, which serves as a bridge between the POSIX.1 API
and the MS‑Windows API, and upon which all 
Cygwin applications are dependent; consequently,
Cygwin applications are not  classified
as native  MS‑Windows applications.
The availability of the POSIX.1 API,
furnished by cygwin1.dll
, does generally reduce
the effort required to port GNU applications to Cygwin,
(for example, POSIX functions such as fork()
,
mmap()
, and ioctl()
may not be
readily  implemented in terms of the MS‑Windows API,
and would require significant  porting
effort — if indeed it is even
feasible — to
support them in MinGW applications);
however, the reduced porting burden of Cygwin does 
incur the cost of the dependency on cygwin1.dll
,
and its attendant commercial,
or strict “copyleft ” (GPL),
licensing requirement.
A contraction of “Minimal SYStem”,
originally conceived by Earnie Boyd, and implemented as
a light‑weight fork of Cygwin‑1.3,
MSYS is a Bourne shell command line interpreter system
for use on the MS‑Windows platform.
Offered as a general purpose alternative to Microsoft’s
cmd.exe
, it is accompanied by a small selection
of Unix tools, making it particularly suitable,
in conjunction with MinGW,
for porting of many Open Source applications
to the MS‑Windows plarform.
Created by Anders Norlander,
w32api
is a system of import libaries, and header files,
complementing Colin Peters’ original bindings for Microsoft’s
CRTDLL.DLL
, by the addition of bindings for Microsoft’s
32‑bit “Windows Application Programming Interface”.
Originally conceived by Earnie Boyd,
and promoted under the name “mingwPORT
”,
this is a system of Bourne shell scripts, designed to facilitate
building of MinGW applications, by end users, directly from the
upstream source code.
Unfortunately, as originally conceived,
the mingwPORT
system exhibited a number of flaws.
In recognition of this, Charles (Chuck) Wilson, developed a replacement,
derived from Cygwin’s “cygport
” system,
which he called “mgwport
”.
This, in turn, was found to be rather unsatisfactory,
and has since been supplanted by the
“mingw-port
” subsidiary of
“the mingw‑pkg
system”.
A list of packages, which are currently
distributed via the mingw‑ports
framework,
may be found within the MinGW File Release System.
Originating in Unix,
and now specified as a formally required POSIX.1 utility,
(and even emulated by Microsoft, with varying degrees of fidelity,
originally preserving the name make
,
and more recently supplanted by nmake
 ),
make
is a utility program to assist in the
maintenance of an entire suite of application software,
(or indeed,
in the maintenance of any suite of published documents
which must be generated from a collection of document source files).
Controlled by a configuration file, known as a makefile
,
(or maybe, by a hierarchical system of makefiles
 ),
which defines a “dependency graph ”,
in which the relationships between generated files
and their respective source files are specified,
together with the sequences of commands which must be executed,
to regenerate each of the generated files from its respective sources,
make
will, when invoked, compare the time‑stamps
of each of the generated files with all 
of its prerequisite source files, and,
for any generated file which does not yet exist,
or is found to be older than
any one  (or more) of its sources,
run the sequence of commands to create, or regenerate that file.
This may offer significant benefit of time saving,
when a large collection of generated files is to be maintained,
since any which are found to be up‑to‑date,
when make
is invoked,
do not need to be generated again.
The MinGW.OSDN Project offers two variants of
the GNU implementation of make
,
(which supports many functional enhancements over traditional Unix
make
, and POSIX make
 ):
a variant simply called make
,
which must be run in the MSYS shell environment,
and a further variant suitable for use from cmd.exe
,
known as mingw32‑make
.
Each of these is used in, fundamentally, the same manner.
However, a discussion of how  to use them would be
too extensive to conveniently cover here;
we suggest that you refer to the online GNU make
manual for guidance.
Presumably, you have exhausted all resources on this web‑site, and  a search of all  of the MinGW mailing‑list archives, (both current, and  historical), and you have found nothing pertinent to your problem. You may  find an answer on some 3rd‑party web‑site; however, caveat emptor : such web‑sites are often sources of ill‑advised, and even downright wrong , information! Instead, we strongly  recommend that you subscribe  to the MinGW‑Users mailing list, post a message explaining your problem, and ask for advice.
To protect the list, and its subscribers, from a proliferation of spam , the MinGW‑Users mailing list will reject any messages which are posted by non‑subscribers; thus, to avoid the rejection notifications, you must  subscribe, and you must  post only  from your subscribed address.
You may not have fully completed the subscription process. After submitting the subscription request form, you will receive a confirmation request, (via e‑mail to the address for which you requested your subscription). You must  respond to this confirmation request, following the instructions contained therein; until you do so, your subscription will not  become active.
If you did not receive a confirmation request, then please check that your e‑mail client, or your service provider, has not directed it into your junk folder, (or any other folder which you may not habitually monitor).
If you believe that you have  completed the subscription process, then please double check that the address from which you are trying to post exactly  matches that which you subscribed. You may wish to use the auto‑responding password reminder request, and/or subscription help request services to verify the status of your subscription; if you submit a request of each type, in this order, and you receive a response to the help request, but you do not receive a password reminder, then there is no active subscription for your address.
If a password reminder request does  elicit a reply, but you still receive rejection notifications when you post to the list, then you may have a legitimate justification to seek administrative assistance.
Absolutely not ! The administrative address is strictly  reserved for administrative communications; if you attempt to abuse it for any other purpose, you will receive no reply.
You should subscribe, and post a message to the MinGW‑Users mailing list. If one of the developers decides that your enquiry merits his, or her attention, he, or she will reply. Any such reply may, or may not, initiate an off‑list dialogue; whether it does so, or not, is at the discretion of the developer; you  have no right to, nor should you have any expectation of, such preferential attention.
There is no formal release schedule. MinGW is developed, and maintained, by a very few unpaid volunteers. Each contributing volunteer will publish updated versions of the packages which they maintain, on an ad hoc  basis, as and when they are ready. Attempting to impose a strict schedule will only engender frustration, and will be counterproductive.
The next release, of whatever package you are waiting for, will be published when it is ready; if you want it sooner, please feel free to contribute to the effort of getting it ready.
Unless your project’s header files are placed in directories
which are already in the compiler’s default “include file
search path”, you  must specify compiler options,
such as “-I
path
”,
“-iquote
path
”, or
“-isystem
path
”,
to indicate where your header files may be found.
A comprehensive discussion of this issue, and potential solutions, may be found in this MinGW user guide.
Assuming that your libraries are correctly named,
according to one of the conventions described in
this user guide, you should add references of the form
“-lname
” for each required library,
ensuring that each such reference is placed after 
all named source and object files which refer to it,
and , if any library refers to another,
that the referring  library is named before 
any to which it refers; (note: in the event of circular references among
libraries — a design fault — this
may require some libraries to be named more than once).
Moreover, if any named library cannot be found in the
linker’s default search path, you may also need to specify
“-L
path
”
options, as advised in
this additional user guide.
No, it is not  a bug. The version of Windows, on which you are working, is fundamentally irrelevant ; what is  important is the extent to which you would like your application to run on older versions of Windows, and, in line with MinGW.OSDN’s legacy platform support policy, the MinGW compiler sets its default level  of API support very  conservatively, to ensure support for all  versions of Windows, from Windows‑NT4 (or Windows‑95) onwards.
Of course,
you may wish to take advantage of some newer API capabilities,
which are not supported on these legacy versions of Windows,
and you are willing to sacrifice legacy support in order to do so.
In this respect,
MinGW and Microsoft’s compilers exhibit similar behaviour,
(although newer versions of Microsoft’s SDK may set a less
conservative level of legacy support);
if you wish to support any API function,
which is not supported by the compiler’s default Windows version,
then the onus is on you  to enable support for the
newer API version,
as stipulated in this Microsoft documentation,
(but note that,
whereas Microsoft no longer offer support for Windows‑2000,
or earlier, nor any version of Windows‑9x,
MinGW does  endeavour to support these legacy Windows versions,
by setting WINVER
and
_WIN32_WINNT
— and
_WIN32_WINDOWS
for
Windows‑9x — to
appropriate values,
as defined in the MinGW version of <sdkddkver.h>
 ).
There are several reasons why the linker may report “undefined reference” errors. Typically, you may be attempting to use a system function, which simply isn’t natively supported on MS‑Windows, (and thus, is not  provided within any MinGW system library); alternatively, you may have neglected to specify some library, which is needed to provide the missing functionality.
If you are certain that neither of these is the problem, then it is likely that you are falling foul of a common issue, which is most often entirely attributable to user error: the GNU linker (and hence, the MinGW linker) is a single pass  linker, and thus, successful linking is crucially dependent  on the order in which source files, object modules, and library references are specified, on the command line; unfortunately, and all too frequently, many users  seem to get this fatally wrong . You must  ensure that every  library reference is placed after  every specified object module, (whether explicitly specified, or implicitly compiled), which depends on it.
Assuming that all of the unresolved references can actually be satisfied, from the set of libraries which have been specified, this is almost certainly another manifestation of the same user error as identified in the previous answer. The order in which sources, object files, and libraries are specified, on the command line, may be incorrect, both  for MinGW, and  for GNU/Linux; however, the ELF version of the GNU linker, as used on GNU/Linux, may forgive unresolved references, in the particular case of symbols which are defined in a prematurely‑specified shared  library, whereas MinGW’s PE‑COFF linker will not  forgive this.
That’s just the way it is. Technically, this is as much an error for the GNU/Linux case, as it is for MinGW; we recommend that you should  correct the errant GNU/Linux usage; you must  correct it for MinGW.
The most common reason,
for executables being larger than expected,
is that they include debugging information ;
(this is added when object modules are compiled with GCC’s
‘‑g
’ option).
Even if you do not use ‘‑g
’,
when compiling your own code,
some of the libraries with which you link,
(including system libraries distributed by MinGW.OSDN),
may incorporate debugging information,
and this can have a significant effect
on the size of executables.
If the size of your executables is inflated by debugging information,
you may use the strip
command to remove it;
alternatively, you may specify GCC’s ‘‑s
’
option, when you link the executables, to achieve the same effect.
Other factors, which may contribute to inflation of the size of executables, and the techniques which may be employed to mitigate them, are discussed in the user guide: HOWTO Reduce the Size of MinGW Executable Files.
The run‑time behaviours  of the two executables should be identical. However, the MinGW GCC compiler does not  guarantee to produce consistent output, between any two compilations of the same source; differences in recorded meta‑data, (e.g. compilation date), will be sufficient to introduce byte‑level diferences; furthermore, there is no guarantee that the ordering of the generated code will remain identical.
It may be possible to achieve consistent output, by patching GCC itself, but doing so is beyond the scope of MinGW’s documentation.
If you see a diagnostic message similar to this:
../include/wx/ctrlsub.h:156: internal error: Segmentation fault
then try running the same compilation command again.
If the same error message is reproduced, then you may have stumbled upon a genuine compiler defect. You should try to create a minimal reproducible test case , (i.e. an SSCCE), and post it, along with a request for advice, on the MinGW‑Users mailing list; others may have already encountered the same problem, and be able to help.
Conversely, if the error is not consistently reproducible , you may have a hardware fault; this third‑party FAQ may help to explain the issue.
As a work‑around, if you have encountered a persistently reproducible  ICE (internal compiler error), then you may be able to circumvent it by recompiling at a different (likely lower) level of optimization; (however, you should not allow this, if successful, to discourage you from reporting the issue).
Firstly, you should double check your own code, to ensure that it is completely valid; sadly, many submitted bug reports turn out to result from user error, so if you are in any  doubt, we recommend that you seek advice from the MinGW‑Users mailing list community, before  filing a formal bug report.
If you do  decide to submit a formal bug report, you should proceed as advised in these bug reporting guidelines.
This depends on the interfaces exposed by the library.
In general, any interface which is exposed using
extern
"C"
linkage, (as is the case for many of the MS‑Windows API
library function interfaces), will be compatible; on the other hand,
interfaces which are exposed using C++
linkage,
(or any other language linkage protocol,
which is not strictly 
extern
"C"
compatible),
are unlikely to be usable.
MinGW’s printf()
does  support
the %ll
format modifier; however, Microsoft’s
MSVCRT.DLL
implementation, (which is what MinGW uses
by default ), does not.
If you want to continue to use the MSVCRT.DLL
implementation of printf()
, then to format a C99
long
long
value, you must use
Microsoft’s non‑standard  I64
format modifier, instead of the standard C99 %ll
modifier.
Conversely, if you prefer C99 standard printf()
compatibility, then you must  elect to use the
libmingwrt.a
implementation of printf()
,
(and its formatted I/O siblings), when you compile your code;
any one  of the following
formally sanctioned 
techniques is sufficient to achieve this:
-posix
option.
__MINGW_ANSI_STDIO__
feature, by editing MinGW’s <features.h>
file;
(supported from libmingwrt.a
version 5.2.1 onwards).
#define
either _GNU_SOURCE
, or
_BSD_SOURCE
, before  any #include
statement, which may cause any system header file to be included;
(neither macro requires an associated value).
#define
_POSIX_C_SOURCE
, with
any of the non‑zero values specified by the POSIX standard;
if unspecified, at the time when the first #include
statement, if any, which causes any system header file to be
included, MinGW will implicitly  behave as if a value
of 200809L
had been specified, but an explicit 
definition is required, to override the MSVCRT.DLL
implementation of printf()
.
#define
_XOPEN_SOURCE
, with any
of the values prescribed by the POSIX standard; once again, such a
definition must  precede all 
#include
statements which may cause inclusion of
any system header file; it has the same effect as an explicit 
definition of _POSIX_C_SOURCE
,
at the equivalent conformity level.