5 * MinGW.OSDN frequently asked questions.
10 * Written by Keith Marshall <keith@users.osdn.me>
11 * Copyright (C) 2021, 2022, 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
50 *   narrow non-breaking space
53 <script class="masthead">
54 set_page( "title", "MinGW.OSDN Frequently Asked Questions" );
55 var group = 0, questions = document.getElementsByClassName( "faq" );
57 function show_answer( item, view )
58 { if( (item = item.nextElementSibling).classList.contains( "answer" ) )
59 item.style.display = view ? "block" : "none";
61 while( group < questions.length )
62 { var entry, query = questions[group++].getElementsByTagName( "button" );
63 for( entry = 0; entry < query.length; entry++ )
64 { query[entry].onclick = function()
65 { show_answer( this, this.classList.toggle( "open" ) ); }
68 </script><!-- masthead -->
69 <p>This document presents a categorized list of questions,
70 and answers, relating to the MinGW.OSDN software distributions,
73 <p>The answer to each question may be revealed,
74 immediately below it, by clicking on the question itself.
75 In the case of questions for which the answer is already visible,
76 a further click on the question will dismiss the view of the answer.
78 <div style="display: none">
79 <!-- template -~- copy & paste next 6 lines to create a Q&A container -->
85 </div><!-- template -->
86 <div class="overlapped faq" id="general">
87 <h3>General Enquiries</h3>
88 <button>What is MinGW?</button>
90 <p>Created by Colin Peters,
91 and released to the public domain,
92 the original MinGW — or “Minimalist GNU for
93 Windows” — was a system of import libraries,
94 header files, and supporting “glue” code,
95 to facilitate the use of Microsoft’s
96 <code>CRTDLL.DLL</code> — and
97 later <code>MSVCRT.DLL</code> — as
98 the primary run‑time support for a native MS‑Windows port
99 of the GNU Compiler Collection (GCC), and its supporting utilities,
100 (which, in turn, were originally provided by Jan‑Jaap van der Heijden).
102 <p>Today, MinGW has become synonymous with the entire system comprising
103 these GNU tools, a significantly extended derivative of Colin’s
104 original run‑time system, together with complementary import libraries,
105 and headers, to facilitate access to the MS‑Windows API, a further
106 collection of complementary libraries, and utilities, and even the native
107 MS‑Windows environment in which they run, providing a complete
108 Open Source programming tool set which is suitable for the development
109 of native MS‑Windows applications, with no implicit dependency on any
110 3rd‑party C‑Runtime DLL.
112 </div><!-- answer -->
113 <button>What is Cygwin, and how does it differ from MinGW?</button>
115 <p>Originated by Steve Chamberlain, in 1995, like MinGW,
116 Cygwin is a system which aims to make (primarily) GNU tools
117 available on the MS‑Windows platform;
118 however, the two systems adopt <em>entirely different</em> 
119 methodologies to achieve this objective.
121 <p>Both systems are based on GNU tooling,
122 and both use the GNU Compiler Collection (GCC) as the means
123 of production for their respective application suites.
124 Since GNU is fundamentally a POSIX system,
125 both MinGW and Cygwin tools exhibit a POSIX feel;
126 however, whereas MinGW strives to minimize its POSIX influence,
127 using the MS‑Windows API <em>directly</em>, 
129 MinGW applications may be classified as <em>native</em> 
130 MS‑Windows applications,
131 Cygwin has a much loftier objective ... it aims to provide a complete
132 emulation of the <em>entire</em>  POSIX.1 API!
133 This emulation is encapsulated within a single <code>cygwin1.dll</code>
134 shared object library, which serves as a bridge between the POSIX.1 API
135 and the MS‑Windows API, and upon which <em>all</em> 
136 Cygwin applications are dependent; consequently,
137 Cygwin applications are <em>not</em>  classified
138 as <em>native</em>  MS‑Windows applications.
140 <p>The availability of the POSIX.1 API,
141 furnished by <code>cygwin1.dll</code>, does generally reduce
142 the effort required to port GNU applications to Cygwin,
143 (for example, POSIX functions such as <code>fork()</code>,
144 <code>mmap()</code>, and <code>ioctl()</code> may not be
145 <em>readily</em>  implemented in terms of the MS‑Windows API,
146 and would require <em>significant</em>  porting
147 effort — if indeed it is even
148 feasible — to
149 support them in MinGW applications);
150 however, the reduced porting burden of Cygwin <em>does</em> 
151 incur the cost of the dependency on <code>cygwin1.dll</code>,
152 and its attendant commercial,
153 or strict “<em>copyleft</em> ” (GPL),
154 licensing requirement.
156 </div><!-- answer -->
157 <button>What is MSYS?</button>
159 <p>A contraction of “Minimal SYStem”,
160 originally conceived by Earnie Boyd, and implemented as
161 a light‑weight fork of Cygwin‑1.3,
162 MSYS is a Bourne shell command line interpreter system
163 for use on the MS‑Windows platform.
164 Offered as a general purpose alternative to Microsoft’s
165 <code>cmd.exe</code>, it is accompanied by a small selection
166 of Unix tools, making it particularly suitable,
167 in conjunction with MinGW,
168 for porting of many Open Source applications
169 to the MS‑Windows plarform.
171 </div><!-- answer -->
172 <button>What is W32API?</button>
174 <p>Created by Anders Norlander,
175 <code>w32api</code> is a system of import libaries, and header files,
176 complementing Colin Peters’ original bindings for Microsoft’s
177 <code>CRTDLL.DLL</code>, by the addition of bindings for Microsoft’s
178 32‑bit “Windows Application Programming Interface”.
180 </div><!-- answer -->
181 <button>What is the “mingw‑ports” framework?</button>
183 <p>Originally conceived by Earnie Boyd,
184 and promoted under the name “<code>mingwPORT</code>”,
185 this is a system of Bourne shell scripts, designed to facilitate
186 building of MinGW applications, by end users, directly from the
187 upstream source code.
189 <p>Unfortunately, as originally conceived,
190 the <code>mingwPORT</code> system exhibited a number of flaws.
191 In recognition of this, Charles (Chuck) Wilson, developed a replacement,
192 derived from Cygwin’s “<code>cygport</code>” system,
193 which he called “<code>mgwport</code>”.
194 This, in turn, was found to be rather unsatisfactory,
195 and has since been supplanted by the
196 “<code>mingw-port</code>” subsidiary of
197 “<a rel="noopener noreferrer" target="_blank"
198 href="https://osdn.net/users/keith/pf/mingw.pkg/"
199 >the <code>mingw‑pkg</code> system</a>”.
201 <p>A list of packages, which are currently
202 distributed via the <code>mingw‑ports</code> framework,
203 may be found within <a rel="noopener noreferrer" target="_blank"
204 href="https://osdn.net/projects/mingw/storage/mingw-ports"
205 >the MinGW File Release System</a>.
207 </div><!-- answer -->
208 <button>What is “make”, and how do I use it?</button>
210 <p>Originating in Unix,
211 and now specified as a formally required POSIX.1 utility,
212 (and even emulated by Microsoft, with varying degrees of fidelity,
213 originally preserving the name <code>make</code>,
214 and more recently supplanted by <code>nmake</code> ),
215 <code>make</code> is a utility program to assist in the
216 maintenance of an entire suite of application software,
218 in the maintenance of any suite of published documents
219 which must be generated from a collection of document source files).
221 <p>Controlled by a configuration file, known as a <code>makefile</code>,
222 (or maybe, by a hierarchical system of <code>makefiles</code> ),
223 which defines a “<em>dependency graph</em> ”,
224 in which the relationships between generated files
225 and their respective source files are specified,
226 together with the sequences of commands which must be executed,
227 to regenerate each of the generated files from its respective sources,
228 <code>make</code> will, when invoked, compare the time‑stamps
229 of each of the generated files with <em>all</em> 
230 of its prerequisite source files, and,
231 for any generated file which does not yet exist,
232 or is found to be older than
233 <em>any one</em>  (or more) of its sources,
234 run the sequence of commands to create, or regenerate that file.
235 This may offer significant benefit of time saving,
236 when a large collection of generated files is to be maintained,
237 since any which are found to be up‑to‑date,
238 when <code>make</code> is invoked,
239 do not need to be generated again.
241 <p>The MinGW.OSDN Project offers two variants of
242 the GNU implementation of <code>make</code>,
243 (which supports many functional enhancements over traditional Unix
244 <code>make</code>, and POSIX <code>make</code> ):
245 a variant simply called <code>make</code>,
246 which must be run in the MSYS shell environment,
247 and a further variant suitable for use from <code>cmd.exe</code>,
248 known as <code>mingw32‑make</code>.
249 Each of these is used in, fundamentally, the same manner.
250 However, a discussion of <em>how</em>  to use them would be
251 too extensive to conveniently cover here;
252 we suggest that you refer to <a target="_blank" rel="noopener noreferrer"
253 href="https://www.gnu.org/software/make/manual/"
254 >the online GNU <code>make</code> manual</a> for guidance.
256 </div><!-- answer -->
257 <button>How can I get help, if I can’t find an answer here?</button>
260 you have exhausted all resources on this web‑site,
261 <em>and</em>  a search of <em>all</em> 
262 of the MinGW mailing‑list archives,
264 <em>and</em>  historical),
266 nothing pertinent to your problem.
267 You <em>may</em>  find an answer
268 on some 3rd‑party web‑site;
270 <em>caveat emptor</em> : such web‑sites are often
271 sources of ill‑advised,
272 and even <em>downright wrong</em> ,
275 we <em>strongly</em>  recommend that
276 you <em>subscribe</em>  to the
277 <a target="_blank" href="index.html?page=mailing.html#mingw-users"
278 >MinGW‑Users mailing list</a>,
279 post a message explaining your problem,
282 </div><!-- answer -->
283 <button>Why do I receive persistent rejection notifications,
284 when I attempt to post messages to the MinGW‑Users mailing list?
287 <p>To protect the list, and its subscribers,
288 from a proliferation of <em>spam</em> , the
289 <a target="_blank" href="index.html?page=mailing.html#mingw-users"
290 >MinGW‑Users mailing list</a> will reject any messages
291 which are posted by non‑subscribers;
292 thus, to avoid the rejection notifications, you <em>must</em> 
293 <a rel="noopener noreferrer" target="_blank"
294 href="https://lists.osdn.me/mailman/listinfo/mingw-users"
295 >subscribe</a>, and you <em>must</em>  post <em>only</em> 
296 from your subscribed address.
298 </div><!-- answer -->
299 <button>I <em>have</em> 
300 subscribed to the MinGW‑Users mailing list;
301 why do I continue to receive rejection notifications,
302 when I post messages?
305 <p>You may not have fully completed the subscription process.
306 After submitting the <a rel="noopener noreferrer" target="_blank"
307 href="https://lists.osdn.me/mailman/listinfo/mingw-users"
308 >subscription request form</a>, you will receive a confirmation request,
309 (via e‑mail to the address for which you requested your subscription).
310 You <em>must</em>  respond to this confirmation request,
311 following the instructions contained therein;
312 until you do so, your subscription will <em>not</em>  become active.
314 <p>If you did not receive a confirmation request,
315 then please check that your e‑mail client, or your service provider,
316 has not directed it into your junk folder, (or any other folder which you
317 may not habitually monitor).
319 <p>If you believe that you <em>have</em> 
320 completed the subscription process,
321 then please double check that the address from which you are trying to post
322 <em>exactly</em>  matches that which you subscribed.
323 You may wish to use the auto‑responding
324 <a href="mailto:mingw-users-request@lists.osdn.me?subject=password"
325 >password reminder request</a>, and/or
326 <a href="mailto:mingw-users-request@lists.osdn.me?subject=help"
327 >subscription help request</a> services to verify the status
328 of your subscription; if you submit a request of each type,
329 in this order, and you receive a response to the help request,
330 but you do not receive a password reminder,
331 then there is no active subscription for your address.
333 <p>If a password reminder request <em>does</em>  elicit a reply,
334 but you still receive rejection notifications when you post to the list,
335 then you may have a legitimate justification to
336 <a href="mailto:mingw-users-owner@lists.osdn.me"
337 >seek administrative assistance</a>.
339 </div><!-- answer -->
340 <button>Can I use the administrative address
341 to communicate with the MinGW Developers?
344 <p><em>Absolutely not</em> !
345 The administrative address is <em>strictly</em>  reserved for
346 administrative communications; if you attempt to abuse it for
347 any other purpose, you will receive no reply.
349 </div><!-- answer -->
350 <button>If I cannot use the administrative address,
351 what mechanism <em>is</em>  available for direct communication
352 with the MinGW Developers?
355 <p>You should subscribe, and post a message to the
356 <a target="_blank" href="index.html?page=mailing.html#mingw-users"
357 >MinGW‑Users mailing list</a>.
358 If one of the developers decides that your enquiry merits his,
359 or her attention, he, or she will reply.
360 Any such reply may, or may not, initiate an off‑list dialogue;
361 whether it does so, or not, is at the discretion of the developer;
362 <em>you</em>  have no right to,
363 nor should you have any expectation of,
364 such preferential attention.
366 </div><!-- answer -->
367 <button>Is there a release schedule for MinGW software packages?
368 If there is, where can I find it?
371 <p>There is no formal release schedule.
372 MinGW is developed, and maintained, by a very few unpaid volunteers.
373 Each contributing volunteer will publish updated versions of the packages
375 on an <em>ad hoc</em>  basis, as and when they are ready.
376 Attempting to impose a strict schedule will only engender frustration,
377 and will be counterproductive.
379 <p>The next release, of whatever package you are waiting for,
380 will be published when it is ready; if you want it sooner,
381 please feel free to contribute to the effort of getting it ready.
383 </div><!-- answer -->
385 <div class="overlapped faq" id="compiling">
386 <h3>Compiling and Linking Issues</h3>
387 <button>Why can’t the MinGW compilers find my project’s
391 <p>Unless your project’s header files are placed in directories
392 which are already in the compiler’s default “include file
393 search path”, <em>you</em>  must specify compiler options,
394 such as “<code>-I</code> <code><em>path</em></code> ”,
395 “<code>-iquote</code> <code><em>path</em></code> ”, or
396 “<code>-isystem</code> <code><em>path</em></code> ”,
397 to indicate where your header files may be found.
399 <p>A comprehensive discussion of this issue, and potential solutions,
400 may be found in <a target="_blank" href="index.html?page=isystem.html"
401 >this MinGW user guide</a>.
403 </div><!-- answer -->
404 <button>How do I specify the libraries to be searched by the MinGW linker?
407 <p>Assuming that your libraries are correctly named,
408 according to one of the conventions described in
409 <a target="_blank" href="index.html?page=libspec.html"
410 >this user guide</a>, you should add references of the form
411 “<code>-l<em>name</em></code> ” for each required library,
412 ensuring that each such reference is placed <em>after</em> 
413 all named source and object files which refer to it,
414 <em>and</em> , if any library refers to another,
415 that the <em>referring</em>  library is named <em>before</em> 
416 any to which it refers; (note: in the event of circular references among
417 libraries — a design fault — this
418 may require some libraries to be named more than once).
420 <p>Moreover, if any named library cannot be found in the
421 linker’s default search path, you may also need to specify
422 “<code>-L</code> <code><em>path</em></code> ”
423 options, as advised in
424 <a target="_blank" href="index.html?page=libpath.html"
425 >this additional user guide</a>.
427 </div><!-- answer -->
428 <button>I’m working on Windows‑XP,
429 but the MinGW compiler doesn’t seem to recognize this;
433 <p>No, it is <em>not</em>  a bug.
434 The version of Windows, on which you are working,
435 is <em>fundamentally irrelevant</em> ;
436 what <em>is</em>  important is the extent to which
437 you would like your application to run on older versions of Windows,
438 and, in line with MinGW.OSDN’s legacy platform support policy,
439 the MinGW compiler sets its <em>default level</em>  of API
440 support <em>very</em>  conservatively,
441 to ensure support for <em>all</em>  versions of Windows,
442 from Windows‑NT4 (or Windows‑95) onwards.
445 you may wish to take advantage of some newer API capabilities,
446 which are not supported on these legacy versions of Windows,
447 and you are willing to sacrifice legacy support in order to do so.
449 MinGW and Microsoft’s compilers exhibit similar behaviour,
450 (although newer versions of Microsoft’s SDK may set a less
451 conservative level of legacy support);
452 if you wish to support any API function,
453 which is not supported by the compiler’s default Windows version,
454 then the onus is on <em>you</em>  to enable support for the
456 as stipulated in <a target="_blank" rel="noopener noreferrer"
457 href="https://docs.microsoft.com/en-gb/cpp/porting/modifying-winver-and-win32-winnt"
458 >this Microsoft documentation</a>,
460 whereas Microsoft no longer offer support for Windows‑2000,
461 or earlier, nor any version of Windows‑9x,
462 MinGW <em>does</em>  endeavour to support these legacy Windows versions,
463 by setting <code>WINVER</code> and
464 <code>_WIN32_WINNT</code> — and
465 <code>_WIN32_WINDOWS</code> for
466 Windows‑9x — to
468 as defined in the MinGW version of <code><sdkddkver.h></code> ).
470 </div><!-- answer -->
471 <button>Why does the MinGW linker
472 persistently report “undefined reference” errors,
473 when I have specified all of the libraries
474 which are required to link my application?
477 <p>There are several reasons why the linker may report
478 “undefined reference” errors.
479 Typically, you may be attempting to use a system function,
480 which simply isn’t natively supported on MS‑Windows,
481 (and thus, is <em>not</em>  provided within any MinGW system library);
482 alternatively, you may have neglected to specify some library,
483 which is needed to provide the missing functionality.
485 <p>If you are certain that neither of these is the problem,
486 then it is likely that you are falling foul of a common issue,
487 which is most often entirely attributable to user error:
488 the GNU linker (and hence, the MinGW linker)
489 is a <em>single pass</em>  linker, and thus,
490 successful linking is <em>crucially dependent</em>  on
491 the order in which source files, object modules,
492 and library references are specified,
495 and all too frequently,
496 many <em>users</em>  seem to get this <em>fatally wrong</em> .
497 You <em>must</em>  ensure that <em>every</em>  library reference
498 is placed <em>after</em>  every specified object module,
499 (whether explicitly specified, or implicitly compiled),
502 </div><!-- answer -->
503 <button>Why does a compile and link command,
504 which works fine on GNU/Linux,
505 report “undefined reference” errors,
506 when invoked <em>identically</em>  on MinGW?
510 all of the unresolved references can actually be satisfied,
511 from the set of libraries which have been specified,
512 this is almost certainly another manifestation
513 of the same user error as identified in the previous answer.
514 The order in which sources, object files, and libraries
515 are specified, on the command line, may be incorrect,
516 <em>both</em>  for MinGW, <em>and</em>  for GNU/Linux;
517 however, the ELF version of the GNU linker,
518 as used on GNU/Linux, may forgive unresolved references,
519 in the particular case of symbols which are defined
520 in a prematurely‑specified <em>shared</em>  library,
521 whereas MinGW’s PE‑COFF linker will <em>not</em> 
524 <p>That’s just the way it is.
525 Technically, this is as much an error for the GNU/Linux case,
526 as it is for MinGW; we recommend that you <em>should</em> 
527 correct the errant GNU/Linux usage; you <em>must</em> 
528 correct it for MinGW.
530 </div><!-- answer -->
531 <button>My application compiles, and links fine,
532 but the executable is <em>huge</em> ; why is this?
535 <p>The most common reason,
536 for executables being larger than expected,
537 is that they include <em>debugging information</em> ;
538 (this is added when object modules are compiled with GCC’s
539 ‘<code>‑g</code>’ option).
540 Even if you do not use ‘<code>‑g</code>’,
541 when compiling your own code,
542 some of the libraries with which you link,
543 (including system libraries distributed by MinGW.OSDN),
544 may incorporate debugging information,
545 and this can have a significant effect
546 on the size of executables.
548 <p>If the size of your executables is inflated by debugging information,
549 you may use the <code>strip</code> command to remove it;
550 alternatively, you may specify GCC’s ‘<code>‑s</code>’
551 option, when you link the executables, to achieve the same effect.
554 which may contribute to inflation of the size of executables,
555 and the techniques which may be employed to mitigate them,
556 are discussed in the user guide:
557 <a target="_blank" href="index.html?page=exesize.html"
558 >HOWTO Reduce the Size of MinGW Executable Files</a>.
560 </div><!-- answer -->
561 <button>Why does a recompiled executable differ from the original,
562 when I haven’t changed the source, or any compiler options?
565 <p>The <em>run‑time behaviours</em>  of
566 the two executables should be identical.
567 However, the MinGW GCC compiler <em>does not</em>  guarantee
568 to produce consistent output, between any two compilations of the
569 same source; differences in recorded meta‑data, (e.g.
570 compilation date), will be sufficient to introduce byte‑level
571 diferences; furthermore, there is no guarantee that the ordering
572 of the generated code will remain identical.
574 <p>It may be possible to achieve consistent output,
575 by patching GCC itself, but doing so is beyond the scope
576 of MinGW’s documentation.
578 </div><!-- answer -->
579 <button>What should I do when the compiler reports an
580 “internal error”?
583 <p>If you see a diagnostic message similar to this:
584 </p><pre class="box-out">
585 ../include/wx/ctrlsub.h:156: internal error: Segmentation fault
586 </pre><p>then try running the same compilation command again.
588 <p>If the same error message is reproduced,
589 then you may have stumbled upon a genuine compiler defect.
590 You should try to create a <em>minimal reproducible test case</em> ,
591 (i.e. an <a rel="noopener noreferrer" target="_blank"
592 href="http://www.sscce.org"
593 >SSCCE</a>), and post it, along with a request for advice, on the
594 <a target="_blank" href="index.html?page=mailing.html#mingw-users"
595 >MinGW‑Users mailing list</a>;
596 others may have already encountered the same problem,
600 if the error is <em>not consistently reproducible</em> ,
601 you may have a hardware fault;
602 <a rel="noopener noreferrer" target="_blank"
603 href="https://www.bitwizard.nl/sig11/"
604 >this third‑party FAQ</a> may help to explain the issue.
606 <p>As a work‑around,
607 if you have encountered a <em>persistently reproducible</em> 
608 <dfn>ICE</dfn> (internal compiler error), then you may be able
609 to circumvent it by recompiling at a different (likely lower)
610 level of optimization; (however, you should not allow this,
611 if successful, to discourage you from reporting the issue).
613 </div><!-- answer -->
614 <button>I believe I have identified a MinGW bug; how should I report it?
618 you should double check your own code,
619 to ensure that it is completely valid;
621 many submitted bug reports turn out to result from user error,
622 so if you are in <em>any</em>  doubt,
623 we recommend that you seek advice from
624 <a target="_blank" href="index.html?page=mailing.html#mingw-users"
625 >the MinGW‑Users mailing list</a> community,
626 <em>before</em>  filing a formal bug report.
628 <p>If you <em>do</em>  decide to submit a formal bug report,
629 you should proceed as advised in
630 <a target="_blank" href="index.html?page=buginfo.html"
631 >these bug reporting guidelines</a>.
633 </div><!-- answer -->
635 <div class="overlapped faq" id="portability">
636 <h3>Software Portability Issues</h3>
637 <button>Can I use libraries compiled by other compilers,
638 (e.g. MSVC), with MinGW?
641 <p>This depends on the interfaces exposed by the library.
642 In general, any interface which is exposed using
643 <code>extern</code> <code>"C"</code>
644 linkage, (as is the case for many of the MS‑Windows API
645 library function interfaces), will be compatible; on the other hand,
646 interfaces which are exposed using <code>C++</code> linkage,
647 (or any other language linkage protocol,
648 which is not <em>strictly</em> 
649 <code>extern</code> <code>"C"</code> compatible),
650 are unlikely to be usable.
652 </div><!-- answer -->
653 <button>MinGW’s <code>printf()</code> doesn’t seem
654 to support the C99 <code>%ll</code> format modifier; how can I format
655 a C99 <code>long</code> <code>long</code> value?
658 <p>MinGW’s <code>printf()</code> <em>does</em>  support
659 the <code>%ll</code> format modifier; however, Microsoft’s
660 <code>MSVCRT.DLL</code> implementation, (which is what MinGW uses
661 <em>by default</em> ), does not.
663 <p>If you want to continue to use the <code>MSVCRT.DLL</code>
664 implementation of <code>printf()</code>, then to format a C99
665 <code>long</code> <code>long</code> value, you must use
666 Microsoft’s <em>non‑standard</em>  <code>I64</code>
667 format modifier, instead of the standard C99 <code>%ll</code> modifier.
669 <p>Conversely, if you prefer C99 standard <code>printf()</code>
670 compatibility, then you <em>must</em>  elect to use the
671 <code>libmingwrt.a</code> implementation of <code>printf()</code>,
672 (and its formatted I/O siblings), when you compile your code;
673 <em>any one</em>  of the following
674 <em>formally sanctioned</em> 
675 techniques is sufficient to achieve this:
676 </p><ul style="margin-left: -0.8em">
677 <li>Compile your code with GCC’s <code>-posix</code> option.
679 <li>Permanently <em>enable</em>  the <code>__MINGW_ANSI_STDIO__</code>
680 feature, by editing MinGW’s <code><features.h></code> file;
681 (supported from <code>libmingwrt.a</code> version 5.2.1 onwards).
683 <li><code>#define</code> either <code>_GNU_SOURCE</code>, or
684 <code>_BSD_SOURCE</code>, <em>before</em>  any <code>#include</code>
685 statement, which may cause any system header file to be included;
686 (neither macro requires an associated value).
688 <li><code>#define</code> <code>_POSIX_C_SOURCE</code>, with
689 any of the non‑zero values specified by the POSIX standard;
690 if unspecified, at the time when the first <code>#include</code>
691 statement, if any, which causes any system header file to be
692 included, MinGW will <em>implicitly</em>  behave as if a value
693 of <code>200809L</code> had been specified, but an <em>explicit</em> 
694 definition is required, to override the <code>MSVCRT.DLL</code>
695 implementation of <code>printf()</code>.
697 <li><code>#define</code> <code>_XOPEN_SOURCE</code>, with any
698 of the values prescribed by the POSIX standard; once again, such a
699 definition <em>must</em>  precede <em>all</em> 
700 <code>#include</code> statements which may cause inclusion of
701 any system header file; it has the same effect as an <em>explicit</em> 
702 definition of <code>_POSIX_C_SOURCE</code>,
703 at the equivalent conformity level.
705 </div><!-- answer -->
708 <!-- $RCSfile$: end of file -->
OSDN Git Service
