5 * MinGW.OSDN frequently asked questions.
10 * Written by Keith Marshall <keith@users.osdn.me>
11 * Copyright (C) 2021, MinGW.OSDN Project
14 * Redistribution and use in source and 'compiled' forms (SGML, HTML,
15 * PDF, PostScript, RTF, etc) with or without modification, are permitted
16 * provided that the following conditions are met:
18 * 1. Redistributions of source code must retain the above copyright
19 * notice, this list of conditions and the following disclaimer as
20 * the first lines of this file, unmodified.
22 * 2. Redistributions in compiled form (transformed to other DTDs,
23 * converted to PDF, PostScript, RTF and other formats) must
24 * reproduce the above copyright notice, this list of conditions
25 * and the following disclaimer in the documentation and/or other
26 * materials provided with the distribution.
28 * THIS DOCUMENTATION IS PROVIDED BY THE MINGW.OSDN PROJECT "AS IS"
29 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
30 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
31 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE MINGW.OSDN PROJECT, OR
32 * ITS CONTRIBUTORS, BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
33 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
34 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
35 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
36 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
37 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
38 * OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
42 * Note: this page assumes browser support for the following numeric
45 * ‑ non-breaking hyphen
46 * ‘ typographic left (opening) single quote
47 * ’ typographic apostrophe/right (closing) single quote
48 * “ typographic left (opening) double quote
49 * ” typographic right (closing) double quote
52 <script class="masthead">
53 set_page( "title", "MinGW.OSDN Frequently Asked Questions" );
54 var group = 0, questions = document.getElementsByClassName( "faq" );
56 function show_answer( item, view )
57 { if( (item = item.nextElementSibling).classList.contains( "answer" ) )
58 item.style.display = view ? "block" : "none";
60 while( group < questions.length )
61 { var entry, query = questions[group++].getElementsByTagName( "button" );
62 for( entry = 0; entry < query.length; entry++ )
63 { query[entry].onclick = function()
64 { show_answer( this, this.classList.toggle( "open" ) ); }
67 </script><!-- masthead -->
68 <p>This document presents a categorized list of questions,
69 and answers, relating to the MinGW.OSDN software distributions,
72 <p>The answer to each question may be revealed,
73 immediately below it, by clicking on the question itself.
74 In the case of questions for which the answer is already visible,
75 a further click on the question will dismiss the view of the answer.
77 <div style="display: none">
78 <!-- template -~- copy & paste next 6 lines to create a Q&A container -->
84 </div><!-- template -->
85 <div class="overlapped faq" id="general">
86 <h3>General Enquiries</h3>
87 <button>What is MinGW?</button>
89 <p>Created by Colin Peters,
90 and released to the public domain,
91 the original MinGW — or “Minimalist GNU for Windows”
92 — was a system of import libraries, header files, and supporting
93 “glue” code, to facilitate the use of Microsoft’s
94 <code>CRTDLL.DLL</code> — and later <code>MSVCRT.DLL</code> —
95 as the primary run‑time support for a native MS‑Windows port
96 of the GNU Compiler Collection (GCC), and its supporting utilities,
97 (which, in turn, were originally provided by Jan‑Jaap van der Heijden).
99 <p>Today, MinGW has become synonymous with the entire system comprising
100 these GNU tools, a significantly extended derivative of Colin’s
101 original run‑time system, together with complementary import libraries,
102 and headers, to facilitate access to the MS‑Windows API, a further
103 collection of complementary libraries, and utilities, and even the native
104 MS‑Windows environment in which they run, providing a complete
105 Open Source programming tool set which is suitable for the development
106 of native MS‑Windows applications, with no implicit dependency on any
107 3rd‑party C‑Runtime DLL.
109 </div><!-- answer -->
110 <button>What is MSYS?</button>
112 <p>A contraction of “Minimal SYStem”,
113 originally conceived by Earnie Boyd, and implemented as
114 a light‑weight fork of Cygwin‑1.3,
115 MSYS is a Bourne shell command line interpreter system
116 for use on the MS‑Windows platform.
117 Offered as a general purpose alternative to Microsoft’s
118 <code>cmd.exe</code>, it is accompanied by a small selection
119 of Unix tools, making it particularly suitable,
120 in conjunction with MinGW,
121 for porting of many Open Source applications
122 to the MS‑Windows plarform.
124 </div><!-- answer -->
125 <button>What is W32API?</button>
127 <p>Created by Anders Norlander,
128 <code>w32api</code> is a system of import libaries, and header files,
129 complementing Colin Peters’ original bindings for Microsoft’s
130 <code>CRTDLL.DLL</code>, by the addition of bindings for Microsoft’s
131 32‑bit “Windows Application Programming Interface”.
133 </div><!-- answer -->
134 <button>What is the “mingw‑ports” framework?</button>
136 <p>Originally conceived by Earnie Boyd,
137 and promoted under the name “<code>mingwPORT</code>”,
138 this is a system of Bourne shell scripts, designed to facilitate
139 building of MinGW applications, by end users, directly from the
140 upstream source code.
142 <p>Unfortunately, as originally conceived,
143 the <code>mingwPORT</code> system exhibited a number of flaws.
144 In recognition of this, Charles (Chuck) Wilson, developed a replacement,
145 derived from Cygwin’s “<code>cygport</code>” system,
146 which he called “<code>mgwport</code>”.
147 This, in turn, was found to be rather unsatisfactory,
148 and has since been supplanted by the
149 “<code>mingw-port</code>” subsidiary of
150 “<a rel="noopener noreferrer" target="_blank"
151 href="https://osdn.net/users/keith/pf/mingw.pkg/"
152 >the <code>mingw‑pkg</code> system</a>”.
154 <p>A list of packages, which are currently
155 distributed via the <code>mingw‑ports</code> framework,
156 may be found within <a rel="noopener noreferrer" target="_blank"
157 href="https://osdn.net/projects/mingw/storage/mingw-ports"
158 >the MinGW File Release System</a>.
160 </div><!-- answer -->
161 <button>How can I get help, if I can’t find an answer here?</button>
164 you have exhausted all resources on this web‑site,
165 <em>and</em>  a search of <em>all</em> 
166 of the MinGW mailing‑list archives,
168 <em>and</em>  historical),
170 nothing pertinent to your problem.
171 You <em>may</em>  find an answer
172 on some 3rd‑party web‑site;
174 <em>caveat emptor</em> : such web‑sites are often
175 sources of ill‑advised,
176 and even <em>downright wrong</em> ,
179 we <em>strongly</em>  recommend that
180 you <em>subscribe</em>  to the
181 <a target="_blank" href="index.html?page=mailing.html#mingw-users"
182 >MinGW‑Users mailing list</a>,
183 post a message explaining your problem,
186 </div><!-- answer -->
187 <button>Why do I receive persistent rejection notifications,
188 when I attempt to post messages to the MinGW‑Users mailing list?
191 <p>To protect the list, and its subscribers,
192 from a proliferation of <em>spam</em> , the
193 <a target="_blank" href="index.html?page=mailing.html#mingw-users"
194 >MinGW‑Users mailing list</a> will reject any messages
195 which are posted by non‑subscribers;
196 thus, to avoid the rejection notifications, you <em>must</em> 
197 <a rel="noopener noreferrer" target="_blank"
198 href="https://lists.osdn.me/mailman/listinfo/mingw-users"
199 >subscribe</a>, and you <em>must</em>  post <em>only</em> 
200 from your subscribed address.
202 </div><!-- answer -->
203 <button>I <em>have</em> 
204 subscribed to the MinGW‑Users mailing list;
205 why do I continue to receive rejection notifications,
206 when I post messages?
209 <p>You may not have fully completed the subscription process.
210 After submitting the <a rel="noopener noreferrer" target="_blank"
211 href="https://lists.osdn.me/mailman/listinfo/mingw-users"
212 >subscription request form</a>, you will receive a confirmation request,
213 (via e‑mail to the address for which you requested your subscription).
214 You <em>must</em>  respond to this confirmation request,
215 following the instructions contained therein;
216 until you do so, your subscription will <em>not</em>  become active.
218 <p>If you did not receive a confirmation request,
219 then please check that your e‑mail client, or your service provider,
220 has not directed it into your junk folder, (or any other folder which you
221 may not habitually monitor).
223 <p>If you believe that you <em>have</em> 
224 completed the subscription process,
225 then please double check that the address from which you are trying to post
226 <em>exactly</em>  matches that which you subscribed.
227 You may wish to use the auto‑responding
228 <a href="mailto:mingw-users-request@lists.osdn.me?subject=password"
229 >password reminder request</a>, and/or
230 <a href="mailto:mingw-users-request@lists.osdn.me?subject=help"
231 >subscription help request</a> services to verify the status
232 of your subscription; if you submit a request of each type,
233 in this order, and you receive a response to the help request,
234 but you do not receive a password reminder,
235 then there is no active subscription for your address.
237 <p>If a password reminder request <em>does</em>  elicit a reply,
238 but you still receive rejection notifications when you post to the list,
239 then you may have a legitimate justification to
240 <a href="mailto:mingw-users-owner@lists.osdn.me"
241 >seek administrative assistance</a>.
243 </div><!-- answer -->
244 <button>Can I use the administrative address
245 to communicate with the MinGW Developers?
248 <p><em>Absolutely not</em> !
249 The administrative address is <em>strictly</em>  reserved for
250 administrative communications; if you attempt to abuse it for
251 any other purpose, you will receive no reply.
253 </div><!-- answer -->
254 <button>If I cannot use the administrative address,
255 what mechanism <em>is</em>  available for direct communication
256 with the MinGW Developers?
259 <p>You should subscribe, and post a message to the
260 <a target="_blank" href="index.html?page=mailing.html#mingw-users"
261 >MinGW‑Users mailing list</a>.
262 If one of the developers decides that your enquiry merits his,
263 or her attention, he, or she will reply.
264 Any such reply may, or may not, initiate an off‑list dialogue;
265 whether it does so, or not, is at the discretion of the developer;
266 <em>you</em>  have no right to,
267 nor should you have any expectation of,
268 such preferential attention.
270 </div><!-- answer -->
271 <button>Is there a release schedule for MinGW software packages?
272 If there is, where can I find it?
275 <p>There is no formal release schedule.
276 MinGW is developed, and maintained, by a very few unpaid volunteers.
277 Each contributing volunteer will publish updated versions of the packages
279 on an <em>ad hoc</em>  basis, as and when they are ready.
280 Attempting to impose a strict schedule will only engender frustration,
281 and will be counterproductive.
283 <p>The next release, of whatever package you are waiting for,
284 will be published when it is ready; if you want it sooner,
285 please feel free to contribute to the effort of getting it ready.
287 </div><!-- answer -->
289 <div class="overlapped faq" id="compiling">
290 <h3>Compiling and Linking Issues</h3>
291 <button>Why can’t the MinGW compilers find my project’s
295 <p>Unless your project’s header files are placed in directories
296 which are already in the compiler’s default “include file
297 search path”, <em>you</em>  must specify compiler options,
298 such as “<code>-I</code> <code><em>path</em></code> ”,
299 “<code>-iquote</code> <code><em>path</em></code> ”, or
300 “<code>-isystem</code> <code><em>path</em></code> ”,
301 to indicate where your header files may be found.
303 <p>A comprehensive discussion of this issue, and potential solutions,
304 may be found in <a target="_blank" href="index.html?page=isystem.html"
305 >this MinGW user guide</a>.
307 </div><!-- answer -->
308 <button>How do I specify the libraries to be searched by the MinGW linker?
311 <p>Assuming that your libraries are correctly named,
312 according to one of the conventions described in
313 <a target="_blank" href="index.html?page=libspec.html"
314 >this user guide</a>, you should add references of the form
315 “<code>-l<em>name</em></code> ” for each required library,
316 ensuring that each such reference is placed <em>after</em> 
317 all named source and object files which refer to it,
318 <em>and</em> , if any library refers to another,
319 that the <em>referring</em>  library is named <em>before</em> 
320 any to which it refers; (note: in the event of circular
321 references among libraries — a design fault —
322 this may require some libraries to be named more than once).
324 <p>Moreover, if any named library cannot be found in the
325 linker’s default search path, you may also need to specify
326 “<code>-L</code> <code><em>path</em></code> ”
327 options, as advised in
328 <a target="_blank" href="index.html?page=libpath.html"
329 >this additional user guide</a>.
331 </div><!-- answer -->
332 <button>Why does the MinGW linker
333 persistently report “undefined reference” errors,
334 when I have specified all of the libraries
335 which are required to link my application?
338 <p>There are several reasons why the linker may report
339 “undefined reference” errors.
340 Typically, you may be attempting to use a system function,
341 which simply isn’t natively supported on MS‑Windows,
342 (and thus, is <em>not</em>  provided within any MinGW system library);
343 alternatively, you may have neglected to specify some library,
344 which is needed to provide the missing functionality.
346 <p>If you are certain that neither of these is the problem,
347 then it is likely that you are falling foul of a common issue,
348 which is most often entirely attributable to user error:
349 the GNU linker (and hence, the MinGW linker)
350 is a <em>single pass</em>  linker, and thus,
351 successful linking is <em>crucially dependent</em>  on
352 the order in which source files, object modules,
353 and library references are specified,
356 and all too frequently,
357 many <em>users</em>  seem to get this <em>fatally wrong</em> .
358 You <em>must</em>  ensure that <em>every</em>  library reference
359 is placed <em>after</em>  every specified object module,
360 (whether explicitly specified, or implicitly compiled),
363 </div><!-- answer -->
364 <button>Why does a compile and link command,
365 which works fine on GNU/Linux,
366 report “undefined reference” errors,
367 when invoked <em>identically</em>  on MinGW?
371 all of the unresolved references can actually be satisfied,
372 from the set of libraries which have been specified,
373 this is almost certainly another manifestation
374 of the same user error as identified in the previous answer.
375 The order in which sources, object files, and libraries
376 are specified, on the command line, may be incorrect,
377 <em>both</em>  for MinGW, <em>and</em>  for GNU/Linux;
378 however, the ELF version of the GNU linker,
379 as used on GNU/Linux, may forgive unresolved references,
380 in the particular case of symbols which are defined
381 in a prematurely‑specified <em>shared</em>  library,
382 whereas MinGW’s PE‑COFF linker will <em>not</em> 
385 <p>That’s just the way it is.
386 Technically, this is as much an error for the GNU/Linux case,
387 as it is for MinGW; we recommend that you <em>should</em> 
388 correct the errant GNU/Linux usage; you <em>must</em> 
389 correct it for MinGW.
391 </div><!-- answer -->
392 <button>My application compiles, and links fine,
393 but the executable is <em>huge</em> ; why is this?
396 <p>The most common reason,
397 for executables being larger than expected,
398 is that they include <em>debugging information</em> ;
399 (this is added when object modules are compiled with GCC’s
400 ‘<code>‑g</code>’ option).
401 Even if you do not use ‘<code>‑g</code>’,
402 when compiling your own code,
403 some of the libraries with which you link,
404 (including system libraries distributed by MinGW.OSDN),
405 may incorporate debugging information,
406 and this can have a significant effect
407 on the size of executables.
409 <p>If the size of your executables is inflated by debugging information,
410 you may use the <code>strip</code> command to remove it;
411 alternatively, you may specify GCC’s ‘<code>‑s</code>’
412 option, when you link the executables, to achieve the same effect.
415 which may contribute to inflation of the size of executables,
416 and the techniques which may be employed to mitigate them,
417 are discussed in the user guide:
418 <a target="_blank" href="index.html?page=exesize.html"
419 >HOWTO Reduce the Size of MinGW Executable Files</a>.
421 </div><!-- answer -->
422 <button>Why does a recompiled executable differ from the original,
423 when I haven’t changed the source, or any compiler options?
426 <p>The <em>run‑time behaviours</em>  of
427 the two executables should be identical.
428 However, the MinGW GCC compiler <em>does not</em>  guarantee
429 to produce consistent output, between any two compilations of the
430 same source; differences in recorded meta‑data, (e.g.
431 compilation date), will be sufficient to introduce byte‑level
432 diferences; furthermore, there is no guarantee that the ordering
433 of the generated code will remain identical.
435 <p>It may be possible to achieve consistent output,
436 by patching GCC itself, but doing so is beyond the scope
437 of MinGW’s documentation.
439 </div><!-- answer -->
440 <button>What should I do when the compiler reports an
441 “internal error”?
444 <p>If you see a diagnostic message similar to this:
445 </p><pre class="box-out">
446 ../include/wx/ctrlsub.h:156: internal error: Segmentation fault
447 </pre><p>then try running the same compilation command again.
449 <p>If the same error message is reproduced,
450 then you may have stumbled upon a genuine compiler defect.
451 You should try to create a <em>minimal reproducible test case</em> ,
452 (i.e. an <a rel="noopener noreferrer" target="_blank"
453 href="http://www.sscce.org"
454 >SSCCE</a>), and post it, along with a request for advice, on the
455 <a target="_blank" href="index.html?page=mailing.html#mingw-users"
456 >MinGW‑Users mailing list</a>;
457 others may have already encountered the same problem,
461 if the error is <em>not consistently reproducible</em> ,
462 you may have a hardware fault;
463 <a rel="noopener noreferrer" target="_blank"
464 href="https://www.bitwizard.nl/sig11/"
465 >this third‑party FAQ</a> may help to explain the issue.
467 <p>As a work‑around,
468 if you have encountered a <em>persistently reproducible</em> 
469 <dfn>ICE</dfn> (internal compiler error), then you may be able
470 to circumvent it by recompiling at a different (likely lower)
471 level of optimization; (however, you should not allow this,
472 if successful, to discourage you from reporting the issue).
474 </div><!-- answer -->
476 <div class="overlapped faq" id="portability">
477 <h3>Software Portability Issues</h3>
478 <button>Can I use libraries compiled by other compilers,
479 (e.g. MSVC), with MinGW?
482 <p>This depends on the interfaces exposed by the library.
483 In general, any interface which is exposed using
484 <code>extern</code> <code>"C"</code>
485 linkage, (as is the case for many of the MS‑Windows API
486 library function interfaces), will be compatible; on the other hand,
487 interfaces which are exposed using <code>C++</code> linkage,
488 (or any other language linkage protocol,
489 which is not <em>strictly</em> 
490 <code>extern</code> <code>"C"</code> compatible),
491 are unlikely to be usable.
493 </div><!-- answer -->
494 <button>MinGW’s <code>printf()</code> doesn’t seem
495 to support the C99 <code>%ll</code> format modifier; how can I format
496 a C99 <code>long</code> <code>long</code> value?
499 <p>MinGW’s <code>printf()</code> <em>does</em>  support
500 the <code>%ll</code> format modifier; however, Microsoft’s
501 <code>MSVCRT.DLL</code> implementation, (which is what MinGW uses
502 <em>by default</em> ), does not.
504 <p>If you want to continue to use the <code>MSVCRT.DLL</code>
505 implementation of <code>printf()</code>, then to format a C99
506 <code>long</code> <code>long</code> value, you must use
507 Microsoft’s <em>non‑standard</em>  <code>I64</code>
508 format modifier, instead of the standard C99 <code>%ll</code> modifier.
510 <p>Conversely, if you prefer C99 standard <code>printf()</code>
511 compatibility, then you <em>must</em>  elect to use the
512 <code>libmingwrt.a</code> implementation of <code>printf()</code>,
513 (and its formatted I/O siblings), when you compile your code;
514 <em>any one</em>  of the following
515 <em>formally sanctioned</em> 
516 techniques is sufficient to achieve this:
517 </p><ul style="margin-left: -0.8em">
518 <li>Compile your code with GCC’s <code>-posix</code> option.
520 <li>Permanently <em>enable</em>  the <code>__MINGW_ANSI_STDIO__</code>
521 feature, by editing MinGW’s <code><features.h></code> file;
522 (supported from <code>libmingwrt.a</code> version 5.2.1 onwards).
524 <li><code>#define</code> either <code>_GNU_SOURCE</code>, or
525 <code>_BSD_SOURCE</code>, <em>before</em>  any <code>#include</code>
526 statement, which may cause any system header file to be included;
527 (neither macro requires an associated value).
529 <li><code>#define</code> <code>_POSIX_C_SOURCE</code>, with
530 any of the non‑zero values specified by the POSIX standard;
531 if unspecified, at the time when the first <code>#include</code>
532 statement, if any, which causes any system header file to be
533 included, MinGW will <em>implicitly</em>  behave as if a value
534 of <code>200809L</code> had been specified, but an <em>explicit</em> 
535 definition is required, to override the <code>MSVCRT.DLL</code>
536 implementation of <code>printf()</code>.
538 <li><code>#define</code> <code>_XOPEN_SOURCE</code>, with any
539 of the values prescribed by the POSIX standard; once again, such a
540 definition <em>must</em>  precede <em>all</em> 
541 <code>#include</code> statements which may cause inclusion of
542 any system header file; it has the same effect as an <em>explicit</em> 
543 definition of <code>_POSIX_C_SOURCE</code>,
544 at the equivalent conformity level.
546 </div><!-- answer -->
549 <!-- $RCSfile$: end of file -->
OSDN Git Service
