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.

General Enquiries

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.

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.

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 mustsubscribe, 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.

Compiling and Linking Issues

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.

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 reproducibleICE (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.

Software Portability Issues

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 strictlyextern "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‑standardI64 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: