This page is currently in a transitional phase, +as information is transferred from the old Drupal hosted MinGWiki. +

Frequently Asked Questions

Below, you will find references to various tutorials, +MinGW User Guides, and more detailed reference documentation. +If you are uncertain about which reference may be most appropriate +to your needs, you may wish to +consult the FAQ first. +

User Guides

+HOWTO Set Up the MinGW (GCC) Compiler Suite — a Guide for New Users +
+HOWTO Install the MinGW (GCC) Compiler Suite — Manual Method for Expert Users +
+HOWTO Interpret the Names of Packages Distributed by MinGW.OSDN +
+HOWTO Write Specifications for Packages to be Distributed by MinGW.OSDN +

+ +

+HOWTO Build Application Programs with MinGW — A Guide for New Users +
+HOWTO Compile Java Programs with GCJ +
+HOWTO Export a Multiple Instance Supporting C++ Class from a DLL +
+HOWTO Work Around a Linker Lock-Up Problem in Windows‑7 +

+ +

+HOWTO Specify the Include File Search Path for use with MinGW Compilers +
+HOWTO Specify the MinGW Linker’s Search Path for Object Code Libraries +
+HOWTO Customize MinGW Compiler Operation using the GCC ‘specs’ File +
+HOWTO Compile the OpenGL Utility Toolkit (GLUT) for Win32 with MinGW +
+HOWTO Use Mark J. Kilgard's OpenGL Utility Toolkit (GLUT) with MinGW +
+HOWTO Compile and Use the Mpatrol Memory Leak Detection Library +

+ +

+
+

+ +

Reference Documentation

+ + diff --git a/faq.html b/faq.html new file mode 100644 index 0000000..b36da18 --- /dev/null +++ b/faq.html @@ -0,0 +1,549 @@ + + +

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

Compiling and Linking Issues

+ +

Unless your project’ 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 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). +

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 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: +

Compile your code with GCC’s -posix option. +
Permanently enable the __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. +

+ + diff --git a/header.html b/header.html index a7fb252..27b917d 100644 --- a/header.html +++ b/header.html @@ -47,7 +47,7 @@

Frequently Asked Questions

Tutorials

User Guides

Setting Up the MinGW Compiler Suite

Compiling and Linking Programs

Using 3rd‑Party Libraries with MinGW

Reference Documentation

General Enquiries

Compiling and Linking Issues

Software Portability Issues