• R/O
  • HTTP
  • SSH
  • HTTPS

website: Commit

HTML source code, style-sheets, scripts, and images for deployment on mingw.osdn.io


Commit MetaInfo

Revisión6f46c98872322ccd01aff4e3a65ee099d3c32cae (tree)
Tiempo2022-01-01 04:54:28
AutorKeith Marshall <keith@user...>
CommiterKeith Marshall

Log Message

Publish GCC 'specs' customization HOWTO.

* gccspecs.html: New file; adapted from original Drupal content, and
in particular, on user comments relating to that content, this offers
advice on customizing GCC's default behaviour, especially insofar as
it affects include file and library search paths, and the option to
deploy non-free Microsoft C runtime libraries, as alternatives to
pseudo-free MSVCRT.DLL.

Cambiar Resumen

Diferencia incremental

--- /dev/null
+++ b/gccspecs.html
@@ -0,0 +1,1068 @@
1+<!DOCTYPE HTML><!--
2+ *
3+ * gccspecs.html
4+ *
5+ * HOWTO customize GCC behaviour, by modification of an external
6+ * 'specs' file.
7+ *
8+ *
9+ * $Id$
10+ *
11+ * Written by Keith Marshall <keith@users.osdn.me>
12+ * Copyright (C) 2021, MinGW.OSDN Project
13+ *
14+ *
15+ * Redistribution and use in source and 'compiled' forms (SGML, HTML,
16+ * PDF, PostScript, RTF, etc) with or without modification, are permitted
17+ * provided that the following conditions are met:
18+ *
19+ * 1. Redistributions of source code must retain the above copyright
20+ * notice, this list of conditions and the following disclaimer as
21+ * the first lines of this file, unmodified.
22+ *
23+ * 2. Redistributions in compiled form (transformed to other DTDs,
24+ * converted to PDF, PostScript, RTF and other formats) must
25+ * reproduce the above copyright notice, this list of conditions
26+ * and the following disclaimer in the documentation and/or other
27+ * materials provided with the distribution.
28+ *
29+ * THIS DOCUMENTATION IS PROVIDED BY THE MINGW.OSDN PROJECT "AS IS"
30+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
31+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
32+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE MINGW.OSDN PROJECT, OR
33+ * ITS CONTRIBUTORS, BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
34+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
35+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
36+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
37+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
38+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
39+ * OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
40+ * DAMAGE.
41+ *
42+ *
43+ * Note: this page assumes browser support for the following numeric
44+ * HTML entity codes:
45+ *
46+ * &#8197; fixed width 1/4 em space
47+ * &#8209; non-breaking hyphen
48+ * &#8216; typographic left (opening) single quote
49+ * &#8217; typographic apostrophe/right (closing) single quote
50+ * &#8220; typographic left (opening) double quote
51+ * &#8221; typographic right (closing) double quote
52+ *
53+-->
54+<script class="masthead">
55+/* Script fragment, to assign titles specific to this page; this is
56+ * encapsulated within the "masthead", where such titles are displayed,
57+ * to ensure that whatever page content may follow will be correctly
58+ * positioned, relative to the masthead content.
59+ */
60+ set_page("title", "MinGW Compiler Suite User Guide");
61+ set_page("subtitle", "HOWTO Customize the Default Behaviour of the MinGW Compiler");
62+</script><!-- masthead -->
63+<!--<p class="byline">Posted: 2021-07-03, by Keith; Last Update: 2021-07-03</p>-->
64+
65+<div class="overlapped" id="intro">
66+<h3>Introduction</h3>
67+<p>The MinGW compiler comprises a comprehensive suite of separate programs,
68+intended for deployment as a native compiler, on the Microsoft Windows platform,
69+or alternatively, as a cross&#8209;compiler for use on some other platform,
70+to create applications for deployment on the native Windows platform.
71+In either case, the compiler suite consists of, at least:&ndash;
72+</p><ul>
73+<li>The GNU Compiler Collection (GCC),
74+built either as a fully native suite, or as a cross&#8209;compiler suite,
75+with Microsoft Windows as the code&#8209;generator target.
76+</li>
77+<li>The GNU Binutils suite; this comprises, primarily,
78+the GNU assembler, the GNU linker, and the GNU archive librarian,
79+accompanied by a small collection of other utility programs,
80+also built with Microsoft Windows as the code&#8209;generator target.
81+</li>
82+<li>The MinGW C runtime libraries,
83+(which integrate with Microsoft&#8217;s C runtime library),
84+and the MinGW Windows API suite,
85+(which integrates with Microsoft&#8217;s core Windows system DLLs).
86+</li></ul>
87+<p>In addition to the above,
88+a native MinGW compiler deployment is accompanied by several other GNU DLLs,
89+which are required to support the operation of the compiler itself;
90+in the case of a cross&#8209;compiler,
91+the function of these additional DLLs is served by equivalents,
92+which are native to the platform on which the cross&#8209;compiler is run.
93+</p>
94+<p>Regardless of whether it is deployed as a native compiler,
95+or as a cross&#8209;compiler suite,
96+the MinGW compiler, assembler, and linker are normally invoked
97+by means of a common <em>driver</em>&hairsp; program;
98+in the case of a native compiler,
99+this driver program is normally <code>gcc</code>,
100+(or <code>g++</code>, when compiling C++ code);
101+in the case of a cross&#8209;compiler,
102+the corresponding driver programs may be <code>mingw32&#8209;gcc</code>,
103+and <code>mingw32&#8209;g++</code>,
104+(possibly qualified by an additional prefix,
105+to identify the target CPU).
106+In either case,
107+the driver program determines the sequence of auxiliary programs,
108+which are to be executed,
109+and the options and file names which are to be passed to them,
110+on the basis of:&ndash;
111+</p><ul>
112+<li>The options, and file names,
113+which are specified on the command line
114+which invokes the driver program itself.
115+</li>
116+<li>A collection of &#8216;specs&#8217; strings,
117+such as those which are identified in
118+<a rel="noopener noreferrer" target="_blank"
119+ href="http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html"
120+>the relevant section of the GCC on&#8209;line manual</a>;
121+a default set of such &#8216;specs&#8217; strings is
122+compiled into the driver programs,
123+but the user is permitted to modify, and even add to these,
124+and so modify the default behaviour of the compiler.
125+</li></ul>
126+<p>In this HOWTO,
127+we explore the capabilities afforded by &#8216;specs&#8217; string
128+modifications, illustrating these capabilities by examples of:&ndash;
129+</p><ul>
130+<li><a href="#isystem">Adding directories to the include file search path</a>,
131+as recommended in the
132+&#8220;<a target="_blank" href="index.html?page=isystem.html#third-party"
133+>Include File Search Path HOWTO</a>&#8221;,
134+as it relates to the use of third&#8209;party libraries with MinGW.
135+</li>
136+<li><a href="#libpath">Adding directories to the library search path</a>,
137+as recommended in the
138+&#8220;<a target="_blank" href="index.html?page=libpath.html#customize"
139+>Library Search Path HOWTO</a>&#8221;,
140+as it relates to the customization of the default library search path.
141+</li>
142+<li><a href="#msvcrt">Adding support for linking with
143+Microsoft&#8217;s non&#8209;free C runtime libraries</a>,
144+such as those which are distributed with the
145+Microsoft Visual C Compiler suite.
146+</li></ul>
147+</div><!-- intro -->
148+
149+<div class="overlapped" id="prep">
150+<h3>Preparing the GCC &#8216;specs&#8217; for Customization</h3>
151+<p>By default,
152+the behaviour of GCC is controlled by
153+a collection of &#8216;specs&#8217; strings,
154+which are defined at the time when GCC itself is built,
155+and are built&#8209;in to the driver program;
156+such built&#8209;in &#8216;specs&#8217; strings
157+are <em>internally immutable</em>,&hairsp;
158+but any of them may be redefined in <em>external</em>&hairsp;
159+&#8216;specs&#8217; files,
160+thus allowing them to be <em>effectively modified</em>&hairsp;
161+at GCC run&#8209;time.
162+Thus, it should be evident
163+that customization of GCC behaviour will require
164+the use of <em>external</em>&hairsp;
165+&#8216;specs&#8217; files.
166+</p>
167+<p>Before we embark on the customization process,
168+it may be helpful to clarify some aspects of how GCC interprets,
169+&#8216;specs&#8217; files ... an area in which the GCC documentation,
170+and its built&#8209;in help are ambiguously vague!
171+In particular,
172+within the built&#8209;in help:
173+</p>
174+<pre class="vt box-out">
175+$ <kbd>gcc --help</kbd>
176+ :
177+ -specs=&lt;file&gt; Override built-in specs with the contents of &lt;file&gt;.
178+ :
179+</pre>
180+<p>this terse description of the <code>-specs</code> option,
181+while technically accurate,
182+may lead to a misconception that,
183+when this option is specified,
184+GCC will ignore its built&#8209;in &#8216;specs&#8217;
185+<em>in their entirety</em>&hairsp;;
186+however, in reality:
187+</p><ul>
188+<li><em>Before</em>&hairsp; reading <em>any</em>&hairsp; file,
189+which has been nominated with the <code>-specs=&lt;file&gt;</code> option,
190+GCC <em>will</em>,&hairsp; with <em>just one exception</em>,&hairsp;
191+initialize its <em>default &#8216;specs&#8217;</em>&hairsp; state
192+to that which is directed by its built&#8209;in &#8216;specs&#8217;.
193+</li>
194+<li>The <em>one exception</em>&hairsp; to the preceding initialization
195+arises when an <em>external</em>&hairsp; &#8216;specs&#8217; file,
196+<em>explicitly</em>&hairsp; named &#8220;specs&#8221;,
197+is present: in this case,
198+GCC <em>will</em>&hairsp; ignore its built&#8209;in &#8216;specs&#8217;,
199+and will read its default &#8216;specs&#8217; state from this file instead.
200+This explicitly named &#8216;specs&#8217; file need <em>not</em>&hairsp; be
201+invoked by means of a <code>-specs=specs</code> option; (indeed,
202+if it is, it will be read <em>twice</em>,&hairsp;
203+the effect of which is unlikely to be desired).
204+</li>
205+<li>Only <em>after</em>&hairsp;
206+its default &#8216;specs&#8217; state has been initialized,
207+will GCC read <em>any</em>&hairsp; &#8216;specs&#8217; file
208+which has been nominated by means of
209+a <code>-specs=&lt;file&gt;</code> option.
210+Each &#8216;specs&#8217; file so nominated,
211+(more than one is permitted, in which case they will be read
212+in strictly left&#8209;to&#8209;right order, as nominated),
213+will <em>augment</em>&hairsp; the prevailing &#8216;specs&#8217; state,
214+(as it has been established at the time when each file is read);
215+augmentation may:
216+<ol style="list-style: lower-roman">
217+<li><em>Add</em>&hairsp;
218+new <em>custom</em>&hairsp; &#8216;specs&#8217; strings.
219+</li>
220+<li><em>Redefine</em>&hairsp;
221+any <em>existing</em>&hairsp; &#8216;specs&#8217; string,
222+<em>in its entirety</em>&hairsp;;
223+(such redefinition <em>does</em>&hairsp; have the effect of
224+<em>overriding</em>&hairsp; each redefined &#8216;specs&#8217; string,
225+but the effect is <em>selective</em>&hairsp;).
226+</li>
227+<li><em>Append</em>&hairsp; additional text
228+to any <em>existing</em>&hairsp; &#8216;specs&#8217; string;
229+(this <em>modifies</em>&hairsp; the affected &#8216;specs&#8217; string,
230+but does not, strictly speaking, <em>override</em>&hairsp; it).
231+</li>
232+<li><em>Delete</em>&hairsp;
233+any <em>existing</em>&hairsp; &#8216;specs&#8217; string.
234+</li></ol>
235+<li>Compilation ultimately proceeds
236+with whatever &#8216;specs&#8217; state prevails,
237+after all applicable customizations have been processed.
238+</li></ul>
239+<p>Having established an understanding of
240+how GCC processes &#8216;specs&#8217; files,
241+we may now progress to development of our customization strategy.
242+First we must decide, in the case of each planned customization,
243+whether we would like it to affect <em>every</em>&hairsp; GCC invocation,
244+or if it should be subject to selection,
245+by specification of a <code>-specs=&lt;file&gt;</code> option.
246+In the former case,
247+the customization should be applied in a &#8216;specs&#8217; file
248+which overrides all of the built&#8209;in &#8216;specs&#8217;,
249+(i.e.&nbsp;in a file named &#8220;specs&#8221;);
250+in the latter, a selective customization
251+(in a file with any user-chosen name other than &#8220;specs&#8221;)
252+may be more appropriate.
253+</p>
254+<p>Regardless of how any required &#8216;specs&#8217; files are to be named,
255+they <em>must</em>&hairsp; be installed at an appropriate location within the
256+GCC installation directory hierarchy;
257+the appropriate directory path name may be identified,
258+(as in this example for a MinGW installation of GCC-3.4.5),
259+by running the command:
260+</p>
261+<pre class="vt box-out">
262+$ <kbd>gcc -print-libgcc-file-name</kbd>
263+c:/mingw/bin/../lib/gcc/mingw32/3.4.5/libgcc.a
264+</pre>
265+<p>and discarding the final file name component of the path name,
266+to obtain a directory path name resembling
267+<code>c:/mingw/bin/../lib/gcc/mingw32/3.4.5</code>.
268+</p>
269+<p>Note: if you are running this
270+in an MSYS (or other POSIX&#8209;compatible) shell,
271+and assuming that the <code>sed</code> utility program is installed,
272+you may wish to use it, in an adaptation of the preceding command,
273+to obtain the requisite directory path name directly,
274+expressing it in canonical form):
275+</p>
276+<pre class="vt box-out">
277+$ <kbd>gcc -print-libgcc-file-name | sed 's!/[^/]*$!!;:1;s![^/][^/]*/\.\./!/!;t 1'</kbd>
278+c:/mingw/lib/gcc/mingw32/3.4.5
279+</pre>
280+<p>Alternatively, in Microsoft&#8217;s <code>cmd.exe</code> shell,
281+with a suitable POSIX&#8209;compatible <code>sed</code> utility program available,
282+you may use the same adaptation of the command,
283+<em>except</em>&hairsp; that you <em>must</em> substitute double quotes,
284+in place of the single quotes:
285+</p>
286+<pre class="vt box-out">
287+C:\&gt; <kbd>gcc -print-libgcc-file-name | sed "s!/[^/]*$!!;:1;s![^/][^/]*/\.\./!/!;t 1"</kbd>
288+c:/mingw/lib/gcc/mingw32/3.4.5
289+</pre>
290+<p>If you plan to apply any customizations
291+which you wish to take effect <em>every</em>&hairsp; time you run GCC,
292+(i.e.&nbsp;<em>without</em>&hairsp; requiring
293+a <code>-specs=&lt;file&gt;</code> option),
294+then you <em>must</em>&hairsp; apply those customizations
295+within a &#8216;specs&#8217; file which is
296+<em>explicitly</em>&hairsp; named &#8220;specs&#8221;,
297+in the directory which you have just identified,
298+as described above.
299+If such a &#8216;specs&#8217; file already exists,
300+then you are good to go;
301+back it up,
302+(in case you need to revert it ... a mistake in customization
303+could break GCC in some &#8220;interesting&#8221; way),
304+then proceed to edit it,
305+to apply your chosen customizations.
306+Conversely, if no file named &#8220;specs&#8221; yet exists,
307+in the appropriate directory,
308+you must create it.
309+Ideally, you should start from a baseline which <em>exactly</em> reproduces
310+GCC&#8217;s built&#8209;in &#8216;specs&#8217;;
311+you may create, (or subsequently revert to), such a baseline,
312+by running the command:
313+</p>
314+<pre class="vt box-out">
315+$ <kbd>gcc -dumpspecs &gt; c:/path/to/libgcc/dir/specs</kbd>
316+</pre>
317+<p>where <code>/path/to/libgcc/dir</code> represents the path
318+to the directory in which <code>libgcc.a</code> is installed,
319+as you have identified previously, from the output of the
320+<span class="nowrap"><code>gcc -print-libgcc-file-name</code></span> command;
321+(thus, by extension of the earlier example, you would execute):
322+</p>
323+<pre class="vt box-out">
324+$ <kbd>gcc -dumpspecs &gt; c:/mingw/lib/gcc/mingw32/3.4.5/specs</kbd>
325+</pre>
326+</div><!-- prep -->
327+
328+<div class="overlapped" id="isystem">
329+<h3>Defining a Custom Include File Search Path</h3>
330+<p>As noted in the
331+&#8220;<a target="_blank" href="index.html?page=isystem.html"
332+>Include File Search Path HOWTO</a>&#8221;,
333+if a <code>mingw32</code> build of GCC had been
334+configured to run on a typical Unix system,
335+it might be expected to search for include files
336+in <code>/usr/local/include</code>,
337+some GCC and <code>mingw32</code> specific directories,
338+and <code>/usr/include</code>.
339+</p>
340+<p>On its native MS&#8209;Windows host,
341+when installed at its default file system location of <code>C:/MinGW</code>,
342+it may seem reasonable to consider that <code>C:/MinGW</code> could be used
343+as a representative equivalent of the <code>/usr</code> directory
344+of the typical Unix system; thus,
345+<code>C:/MinGW/local/include</code> would be equivalent to
346+the Unix system&#8217;s <code>/usr/local/include</code> directory.
347+However, in a standard <code>mingw32</code> build of GCC,
348+<code>C:/MinGW/local/include</code> is conspicuously <em>omitted</em>&hairsp;
349+from the configured include file search path.
350+</p>
351+<p>On a Unix system,
352+the <code>/usr/local/lib</code> file system hierarchy
353+would typically be used to segregate third&#8209;party,
354+locally installed libraries, from the core system libraries,
355+with the corresponding header files,
356+associated with such locally installed libraries,
357+being placed into the file system hierarchy
358+below <code>/usr/local/include</code>.
359+From a system management perspective,
360+this segregation is very convenient;
361+the absence of a similar file system infrastructure,
362+in a standard MinGW installation,
363+introduces an inconvenience which we would like to mitigate.
364+</p>
365+<p>Of course,
366+having created a supporting directory structure,
367+and installed our third&#8209;party header files within it,
368+we can <em>always</em>&hairsp; instruct GCC to search for them by specifying
369+<code>-I...</code>, <code>-isystem</code>&puncsp;<code>...</code>,
370+or even <code>-iquote</code>&puncsp;<code>...</code> options to GCC commands,
371+or by specifying <code>CPATH=...</code>, <code>C_INCLUDE_PATH=...</code>,
372+<code>CPLUS_INCLUDE_PATH=...</code>, or <code>OBJC_INCLUDE_PATH=...</code>
373+<em>environment variables</em>,&hairsp; as appropriate;
374+of more interest here, however,
375+is the development of an inconvenience mitigating configuration,
376+by means of &#8216;specs&#8217; file customization.
377+</p>
378+<p>Let us assume that we have created a suitable
379+file system hierarchy at <code class="nowrap">C:/MinGW/local</code>,
380+and we have installed our third&#8209;party header files
381+into <code class="nowrap">C:/MinGW/local/include</code>;
382+(we could just as well have chosen a path outside
383+the default MinGW installation hierarchy
384+.&hairsp;.&hairsp;. say <code class="nowrap">C:/Local/MinGW</code>,
385+with header files in
386+<code class="nowrap">C:/Local/MinGW/include</code> .&hairsp;.&hairsp;.
387+but the principle remains the same;
388+we would simply substitute <code class="nowrap">C:/Local/MinGW</code>
389+for <code class="nowrap">C:/MinGW/local</code>,
390+in &#8216;specs&#8217; file references).
391+Given this assumption, as stated,
392+our objective will be to customize the GCC &#8216;specs&#8217; state,
393+such that <code class="nowrap">C:/MinGW/local/include</code> will be searched,
394+as if specified by <code class="nowrap">-isystem C:/MinGW/local/include</code>,
395+<em>every</em>&hairsp; time GCC is invoked.
396+</p>
397+<p>Since we would like this customization to apply for every GCC invocation,
398+the most appropriate place to make the necessary changes is in the external
399+&#8216;specs&#8217; file which is explicitly named &#8220;specs&#8221;,
400+rather than in any which needs to be nominated by specification of
401+a <code>-specs=&lt;file&gt;</code> option.
402+If this file already exists, make a backup copy of it,
403+(in case you mess it up, and need to revert it);
404+if it does not yet exist, create it.
405+(Please refer to <a href="#prep">the preceding section, within this document</a>,
406+for advice on how to locate, or how to create, this &#8220;specs&#8221; file,
407+if you do not already know).
408+</p>
409+<p>Next, open this &#8220;specs&#8221; file
410+in your favourite text&#8209;file editor, and add:
411+</p>
412+<pre class="box-out">
413+*local_prefix:
414+c:/mingw/local/
415+
416+*local_includes:
417+-I %(local_prefix)include
418+
419+</pre>
420+<p>at (or near) the top of the file,
421+taking care to ensure that each of
422+these new custom &#8216;specs&#8217; string definitions,
423+(while also taking care to preserve the same structure
424+for <em>all existing</em>,&hairsp; adjacent definitions),
425+comprises <em>exactly</em>&hairsp;:
426+</p><ul>
427+<li>One line, beginning with an asterisk and ending with a colon,
428+specifying the <em>name</em>&hairsp; of of the custom &#8216;specs&#8217;
429+string, between these punctuation marks.
430+</li>
431+<li>One (or more) non&#8209;blank lines,
432+specifying the <em>value</em>&hairsp; of the named &#8216;specs&#8217; string.
433+</li>
434+<li>One final line, to terminate the &#8216;specs&#8217; string definition;
435+(this line <em>must</em>&hairsp; be <em>completely empty</em>&hairsp;;
436+take care that no white space is accidentally inserted).
437+</li></ul>
438+<p>Finally,
439+to make GCC actually <em>use</em>&hairsp;
440+our <code>local_includes</code> definition,
441+we must append it to each of GCC's own (existing) <code>ccp</code>,
442+and <code>cc1plus</code> definitions.
443+While the &#8220;specs&#8221; file is still open,
444+in your text&#8209;file editor,
445+move to the end of the file,
446+and add:
447+</p>
448+<pre class="box-out">
449+*cpp:
450++ %(local_includes)
451+
452+*cc1plus:
453++ %(local_includes)
454+
455+</pre>
456+<p>(again,
457+taking care to leave the <em>two empty lines</em>,&hairsp;
458+as shown),
459+before saving the file,
460+and quitting from the text&#8209;editor,
461+to complete the modification.
462+</p>
463+<p>Astute readers may have noticed that,
464+to the extent to which this &#8216;specs&#8217; file modification uses it,
465+our definition of <code>local_prefix</code> is effectively redundant;
466+we could just as well have specified the value of
467+<code>local_includes</code> <em>directly</em>,&hairsp;
468+to be <code class="nowrap">-isystem c:/mingw/local/include</code>,
469+and the effect would be the same.
470+We have chosen to define <code>local_prefix</code> separately,
471+because, as we will see in <a href="#libpath">the next section</a>,
472+we will want to define a <code>local_libpath</code> specification,
473+relative to the same file system prefix.
474+Of course, we could also specify <code>local_libpath</code>
475+<em>entirely</em>&hairsp; within a single &#8216;specs&#8217; string,
476+(including a duplicate of the prefix from <code>local_includes</code>);
477+the advantage of defining <code>local_prefix</code> separately,
478+and then relating both <code>local_includes</code>
479+and <code>local_libpath</code> to it,
480+is that it offers us an option,
481+at some unspecified future time,
482+to relocate the <em>entire</em>&hairsp; local file system hierarchy,
483+(from <code>C:/MinGW/local</code> to <code>C:/Local/MinGW</code>,
484+for example), by redefining, or by <em>overriding</em>,&hairsp;
485+just the one <code>local_prefix</code> &#8216;specs&#8217; string.
486+</p>
487+</div><!-- isystem -->
488+
489+<div class="overlapped" id="libpath">
490+<h3>Defining a Custom Library Search Path</h3>
491+<p>Further building on the underlying principles of,
492+and complementing the customized include file search path configuration,
493+as described in <a href="#isystem">the preceding section</a>,
494+GCC also needs to be instructed where to search for the associated
495+third&#8209;party library files.
496+</p>
497+<p>By analogy with the customized local include file search path,
498+which we have configured as <code>c:/mingw/local/include</code>,
499+the logically corresponding local library search path would be
500+<code>c:/mingw/local/lib</code>.
501+While the &#8220;<a target="_blank" href="index.html?page=libpath.html#customize"
502+>Library Search Path HOWTO</a>&#8221; indicates how
503+this search path may be specified,
504+without recourse to &#8216;specs&#8217; file customization,
505+for the additional convenience which it will ultimately afford,
506+we are more interested, here, in how to specify this custom search path
507+<em>using</em>&hairsp; &#8216;specs&#8217; file customization.
508+</p>
509+<p>Like the local include file search path configuration,
510+this &#8216;specs&#8217; file customization will be most convenient
511+if its deployment does <em>not</em>&hairsp; require the use of
512+a <code>-specs=&lt;file&gt;</code> command line option.
513+So, assuming that you have already followed the preceding procedures,
514+to <a href="#prep">provision a primary &#8216;specs&#8217; file</a>,
515+(explicitly named &#8220;specs&#8221;),
516+and to <a href="#isystem">configure the custom include file search path</a>,
517+open this &#8216;specs&#8217; file once again,
518+in your favourite text&#8209;file editor;
519+locate the definition for <code>local_includes</code>,
520+which you added previously, and below it,
521+add the definition:
522+</p>
523+<pre class="box-out">
524+*local_libpath:
525+-L %(local_prefix)lib
526+
527+</pre>
528+<p>once again, taking care to maintain correct structure,
529+both within this new definition, and those adjacent to it.
530+</p>
531+<p>Finally,
532+to complete the configuration,
533+and instruct GCC to <em>use</em>&hairsp; this new custom search path,
534+go to the end of the file, and add:
535+</p>
536+<pre class="box-out">
537+*link_libgcc:
538++ %(local_libpath)
539+
540+</pre>
541+<p>before saving the &#8216;specs&#8217; file,
542+and quitting the editor.
543+</p>
544+</div><!-- libpath -->
545+
546+<div class="overlapped" id="msvcrt">
547+<h3>Supporting Microsoft&#8217;s Non&#8209;Free &#8216;C&#8217; Runtime Libraries</h3>
548+<p>By default, the MinGW compiler/linker combination will link applications,
549+such that they depend on Microsoft&#8217;s <code>MSVCRT.DLL</code>
550+&#8216;C&#8217; runtime library;
551+while not strictly &#8220;free&#8221;,
552+in the sense defined by the GNU General Public Licence,
553+this <em>does</em>,&hairsp; qualify for the GPL linking exemption
554+for integration with non&#8209;free software components,
555+on the basis that it is distributed, by Microsoft,
556+as a standard Windows operating system component.
557+</p>
558+<p>In addition to <code>MSVCRT.DLL</code>,
559+Microsoft also distribute various alternative &#8216;C&#8217; runtime libraries,
560+as components of their &#8220;Visual Studio&#8221;, or &#8220;Visual C&#8221;
561+software development suites.
562+Bearing names such as <span class="nowrap">
563+<code>MSVCR70.DLL</code>&hairsp;<code>..</code>&hairsp;<code>MSVCR120.DLL</code>,
564+</span>these are <em>not</em>&hairsp; distributed as standard components
565+of the Windows operating system;
566+thus, they do <em>not</em>&hairsp; qualify for the GPL linking exemption,
567+and MinGW.OSDN is <em>not</em>&hairsp; licensed to distribute them.
568+</p>
569+<p>Notwithstanding the foregoing licensing restrictions on their use,
570+the non&#8209;free Microsoft &#8216;C&#8217; runtime libraries
571+<em>do</em>&hairsp; introduce a small number of functions,
572+which Microsoft have never incorporated into
573+<code>MSVCRT.DLL</code>;
574+consequently, there may be occasions when users will
575+wish to link their MinGW applications with one of these
576+non&#8209;free &#8216;C&#8217; runtime libraries.
577+While MinGW.OSDN is not licensed to distribute these
578+&#8216;C&#8217; runtime libraries,
579+in DLL form,
580+we <em>can</em>,&hairsp; and <em>do</em>,&hairsp;
581+distribute <em>import libraries</em>&hairsp; which map their entry points,
582+(at least for <span class="nowrap"><code>MSVCR70.DLL</code>&hairsp;<code
583+>..</code>&hairsp;<code>MSVCR100.DLL</code>),</span>
584+so that any users who are prepared to handle the licensing implications,
585+and the provisioning of the DLLs for themselves,
586+may link their MinGW applications with these libraries,
587+if they so wish.
588+</p>
589+<p>Some users may assume, naïvely,
590+that linking with, for example <code>MSVCR80.DLL</code>, would be
591+as simple as adding the <code>-lmsvcr80</code> library specification
592+to the <code>gcc</code> command line;
593+unfortunately, it is <em>not</em>&hairsp; as simple as this!
594+The problem with this naïve approach is twofold:&ndash;
595+</p><ol style="list-style: lower-roman">
596+<li>When linking with <code>-lmsvcr80</code>,
597+it is <em>also necessary</em>&hairsp; to link with <code>-lmoldname80</code>;
598+while it may appear that this would be as simple as
599+also adding <code>-lmoldname80</code>,
600+this is also the wrong way to accomplish the objective!
601+</li>
602+<li>The fundamental reason why it is <em>wrong</em>&hairsp; to simply add
603+<code class="nowrap">-lmoldname80 -lmsvcr80</code>
604+to the <code>gcc</code> command line
605+is that the default GCC &#8216;specs&#8217; strings <em>already add</em>&hairsp;
606+<code class="nowrap">-lmoldname -lmsvcrt</code>
607+to the <em>effective</em>&hairsp; <code>gcc</code> command.
608+Thus, by <em>also</em>&hairsp; adding
609+<code class="nowrap">-lmoldname80 -lmsvcr80</code>,
610+we are asking the linker to search <em>both</em>&hairsp;
611+<code>libmoldname80.a</code> <em>and</em>&hairsp; <code>libmoldname.a</code>,
612+to resolve <code>OLDNAME</code> symbols,
613+<em>and ultimately both</em>&hairsp; <code>libmsvcr80.a</code>
614+<em>and</em>&hairsp; <code>libmsvcrt.a</code>,
615+to resolve &#8216;C&#8217; runtime DLL references.
616+This introduces potential for the linked application to depend on
617+<em>both</em>&hairsp; <code>MSVCR80.DLL</code>
618+<em>and</em>&hairsp; <code>MSVCRT.DLL</code>,
619+which is <em>definitively unsupported</em>&hairsp;;
620+at best, you <em>may</em>&hairsp; be lucky, and get away with it;
621+more likely, your application will be unstable,
622+and may crash and burn at run time,
623+with unpredictable side effects.
624+</li></ol>
625+<p>Thus, we should <em>not</em> simply specify <code>-lmsvcr80</code>,
626+(either free&#8209;standing, or accompanied by <code>-lmoldname80</code>),
627+to the <code>gcc</code> command line, when our intent is to link with
628+<code>MSVCR80.DLL</code>, in preference to <code>MSVCRT.DLL</code>.
629+(Nor, following similar reasoning, should we attempt to substitute
630+any of Microsoft&#8217;s other non&#8209;free &#8216;C&#8217;
631+runtime DLLs, in this manner).
632+Rather, we <em>must</em>&hairsp; modify the GCC &#8216;specs&#8217; strings,
633+such that <em>all</em>&hairsp; existing references to <code>-lmsvcrt</code>,
634+and to <code>-lmoldname</code>, are <em>replaced</em>&hairsp; by
635+<code>-lmsvcr80</code> and <code>-lmoldname80</code>, respectively,
636+(or whatever alternative references are appropriate,
637+for the intended substitute &#8216;C&#8217; runtime DLL).
638+Below, we will explore some methods for achieving this objective.
639+</p>
640+<h4>Identifying the Required &#8216;specs&#8217; String Modifications</h4>
641+<p>As we&#8217;ve seen above,
642+when we wish to link with any of Microsoft&#8217;s non&#8209;free
643+&#8216;C&#8217; runtime libraries,
644+we <em>really</em>&hairsp; ought to modify the GCC &#8216;specs&#8217; strings,
645+to avoid any conflicting application dependencies on <em>both</em>&hairsp;
646+<code>MSVCRT.DLL</code>,
647+and the chosen non&#8209;free DLL.
648+The default libraries specification,
649+for linking with <code>MSVCRT.DLL</code>,
650+is <code class="nowrap">-lmoldname -lmsvcrt</code>;
651+for linking with any of the non&#8209;free &#8216;C&#8217; runtime DLLs,
652+this couplet <em>must</em>&hairsp; be replaced,
653+in any &#8216;specs&#8217; string which includes it,
654+by an alternative couplet selected from the following table:&ndash;
655+</p>
656+<table class="borderless">
657+ <tr>
658+ <th>To Use</th><th>Preprocessor Identification</th><th>Link With Libraries</th>
659+ <th>Remarks</th>
660+ </tr>
661+ <tr class="leaded">
662+ <td><code>MSVCRT.DLL</code></td>
663+ <td /><td><code class="nowrap">-lmoldname -lmsvcrt</code></td>
664+ <td>MinGW default;
665+ no preprocessor identification or &#8216;specs&#8217; changes required
666+ </td>
667+ </tr>
668+ <tr><td><code>MSVCR70.DLL</code></td>
669+ <td><code>-D__MSVCRT_VERSION__=0x0700</code></td>
670+ <td><code class="nowrap">-lmoldname70 -lmsvcr70</code></td>
671+ </tr>
672+ <tr><td><code>MSVCR71.DLL</code></td>
673+ <td><code>-D__MSVCRT_VERSION__=0x0710</code></td>
674+ <td><code class="nowrap">-lmoldname71 -lmsvcr71</code></td>
675+ </tr>
676+ <tr><td><code>MSVCR80.DLL</code></td>
677+ <td><code>-D__MSVCRT_VERSION__=0x0800</code></td>
678+ <td><code class="nowrap">-lmoldname80 -lmsvcr80</code></td>
679+ </tr>
680+ <tr><td><code>MSVCR90.DLL</code></td>
681+ <td><code>-D__MSVCRT_VERSION__=0x0900</code></td>
682+ <td><code class="nowrap">-lmoldname90 -lmsvcr90</code></td>
683+ </tr>
684+ <tr><td><code>MSVCR100.DLL</code></td>
685+ <td><code>-D__MSVCRT_VERSION__=0x1000</code></td>
686+ <td><code class="nowrap">-lmoldname100 -lmsvcr100</code></td>
687+ </tr>
688+ <tr style="display: none"><td><code>MSVCR110.DLL</code></td>
689+ <td><code>-D__MSVCRT_VERSION__=0x1100</code></td>
690+ <td><code class="nowrap">-lmoldname110 -lmsvcr110</code></td>
691+ </tr>
692+ <tr style="display: none"><td><code>MSVCR120.DLL</code></td>
693+ <td><code>-D__MSVCRT_VERSION__=0x1200</code></td>
694+ <td><code class="nowrap">-lmoldname120 -lmsvcr120</code></td>
695+ </tr>
696+</table>
697+<p>Note that,
698+in addition to the alternative libraries couplet,
699+the foregoing table also specifies a &#8220;<em>preprocessor
700+identification</em>&hairsp;&#8221;,
701+for all but the default <code>MSVCRT.DLL</code> case.
702+This should be <em>added</em> to the
703+<code>cpp</code> &#8216;specs&#8217; string,
704+as applicable,
705+to ensure that definitions associated with the selected non&#8209;free
706+runtime library are made visible,
707+when the compiler parses the appropriate &#8216;C&#8217; header files.
708+</p>
709+<h4>A Simplistic Approach to Implementing the &#8216;specs&#8217; Strings Modifications</h4>
710+<p>A simple,
711+although rather naïve,
712+method of implementing the necessary &#8216;specs&#8217; string modifications,
713+might be to create a separate copy of the &#8216;specs&#8217; file,
714+specific to each non&#8209;free runtime DLL
715+which we wish to support.
716+For example,
717+to support linking with <code>MSVCR80.DLL</code>,
718+we might create a copy of an existing external &#8216;specs&#8217; file,
719+(in the appropriate &#8216;specs&#8217; file directory),
720+naming the copy as <code>msvcr80</code>,
721+(or, if we don&#8217;t have an external &#8216;specs&#8217; file,
722+use the <code>gcc -dumpspecs</code> command to create <code>msvcr80</code>,
723+as described under the heading &#8220;<a href="#prep">Preparing the GCC
724+&#8216;specs&#8217; for Customization</a>&#8221;, above).
725+</p>
726+<p>Once we have created a copy of the &#8216;specs&#8217; file,
727+(which we&#8217;ve called <code>msvcr80</code>, in our example case),
728+we may edit it, to implement the required customizations.
729+First, we should locate the <code>cpp</code> string definition ...
730+it should look something like this:
731+</p>
732+<pre class="box-out">
733+*cpp:
734+%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: }
735+
736+</pre>
737+<p>or, if we&#8217;ve already added an additional include file search path:
738+</p>
739+<pre class="box-out">
740+*cpp:
741+%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: }
742+%(local_includes)
743+
744+</pre>
745+<p>to which we must add
746+the appropriate <em>preprocessor identification</em>,&hairsp; string,
747+selected from the table above,
748+(which, in the <code>MSVCR80.DLL</code> case,
749+is <code>-D__MSVCRT_VERSION__=0x0800</code>).
750+Thus, the modified definition becomes:
751+</p>
752+<pre class="box-out">
753+*cpp:
754+%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: }
755+-D__MSVCRT_VERSION__=0x0800
756+
757+</pre>
758+<p>or:</p>
759+<pre class="box-out">
760+*cpp:
761+%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: }
762+%(local_includes) -D__MSVCRT_VERSION__=0x0800
763+
764+</pre>
765+<p style="margin-top: 0.8em">Second,
766+we must locate all occurrences of <code>-lmsvcrt</code>,
767+and of <code>-lmoldname</code>,
768+and replace each with the corresponding equivalents from the table above,
769+(<span class="nowrap">i.e.&#8197;<code>-lmsvcr80</code></span>
770+and <code>-lmoldname80</code>, respectively,
771+in the case of the <code>MSVCR80.DLL</code> example).
772+Typically, each will appear just once,
773+with both in the <code>libgcc</code> string definition,
774+which initially, should look something like:
775+</p>
776+<pre class="box-out">
777+*libgcc:
778+%{mthreads:-lmingwthrd} -lmingw32 -lmingwex -lmingw32 -lmingwex
779+%{static|static-libgcc:-lgcc -lgcc_eh} %{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh}
780+%{shared-libgcc:-lgcc_s -lgcc}} %{shared:-lgcc_s -lgcc}}} -lmoldname -lmsvcrt
781+
782+</pre>
783+<p>and, after modification, should look like this:
784+</p>
785+<pre class="box-out">
786+*libgcc:
787+%{mthreads:-lmingwthrd} -lmingw32 -lmingwex -lmingw32 -lmingwex
788+%{static|static-libgcc:-lgcc -lgcc_eh} %{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh}
789+%{shared-libgcc:-lgcc_s -lgcc}} %{shared:-lgcc_s -lgcc}}} -lmoldname80 -lmsvcr80
790+
791+</pre>
792+<p style="margin-top: 0.8em">Finally,
793+while these two modifications are sufficient for <code>gcc</code>,
794+they will <em>not</em>&hairsp; pass the correct <code>__MSVCRT_VERSION__</code>
795+definition for compilation with <code>g++</code>;
796+to correct this deficiency,
797+we must also modify the <code>cc1plus</code> &#8216;specs&#8217; string,
798+(which, unless we've already added anything to it,
799+appears to be initially empty, by default), so we define it as:
800+<pre class="box-out">
801+*cc1plus:
802+-D__MSVCRT_VERSION__=0x0800
803+
804+</pre>
805+<p>or, if we had already added, e.g. an additional include files search path:
806+</p>
807+<pre class="box-out">
808+*cc1plus:
809+%(local_includes) -D__MSVCRT_VERSION__=0x0800
810+
811+</pre>
812+<p style="margin-top: 0.8em">
813+With all three of the above modifications in place,
814+in the <code>msvcr80</code> &#8216;specs&#8217; file,
815+we may invoke <code>gcc</code>, (or <code>g++</code>), like this:
816+</p>
817+<pre class="vt box-out">
818+$ <kbd>gcc -specs=msvcr80 foo.c -o foo.exe</kbd>
819+</pre>
820+<p>to compile, and link <code>foo.exe</code> with <code>MSVCR80.DLL</code>,
821+<em>without</em>&hairsp; incurring any dependency on <code>MSVCRT.DLL</code>.
822+However, the naïve simplicity of this &#8216;specs&#8217; strings
823+modification technique <em>does</em>&hairsp; make it sub&#8209;optimal,
824+and may create potential problems;
825+in the following section,
826+we will discuss possible improvements to this simple modification technique.
827+</p>
828+<h4>Improving on the Simplistic &#8216;specs&#8217; Strings Modification Technique</h4>
829+<p>The simplistic &#8216;specs&#8217; strings modification technique,
830+as described in the preceding section,
831+for supporting the use of Microsoft&#8217;s non&#8209;free
832+&#8216;C&#8217; runtime DLLs,
833+exhibits the following potential disadvantages:&ndash;
834+</p><ul>
835+<li>Each custom &#8216;specs&#8217; file,
836+which relates to any one specific non&#8209;free &#8216;C&#8217; runtime DLL,
837+reproduces a redundant copy of <em>every</em>&hairsp; &#8216;specs&#8217; string
838+which appears in the set of built&#8209;in &#8216;specs&#8217;,
839+(or in an external <code>specs</code> file copy thereof),
840+but modifies <em>only two</em>&hairsp; of them.
841+An implication of this is that <em>every one</em>&hairsp; of those
842+<em>unmodified</em>&hairsp; &#8216;specs&#8217; strings <em>must</em>&hairsp;
843+be parsed <em>twice</em>&hairsp;;
844+this is <em>grossly inefficient</em>.
845+</li>
846+<li>The duplication of all of those <em>unmodified</em>&hairsp;
847+&#8216;specs&#8217; strings is a possible impediment to <em>other</em>&hairsp;
848+(<em>unrelated</em>&hairsp;) customizations;
849+<em>each</em>&hairsp; and <em>every</em>&hairsp; subsequent modification
850+to <em>any</em>&hairsp; of the &#8216;specs&#8217; strings,
851+which are orthogonal to the changes needed to support
852+the non&#8209;free runtime DLLs,
853+<em>must</em>&hairsp; be <em>faithfully reproduced</em>,&hairsp;
854+not only in an external <code>specs</code> file,
855+but <em>also</em>&hairsp; in <em>every</em>&hairsp;
856+non&#8209;free runtime specific auxiliary &#8216;specs&#8217; file;
857+not only is this an undesirable maintenance burden ...
858+it is potentially error&#8209;prone!
859+</li></ul>
860+<p>To some extent,
861+these disadvantages may be mitigated by elimination of
862+<em>all</em>&hairsp; unmodified &#8216;specs&#8217; strings from
863+each of the auxiliary &#8216;specs&#8217; files,
864+leaving the <em>entire</em>&hairsp; content of,
865+for example, the <code>msvcr80</code> &#8216;specs&#8217; file,
866+(incorporating the additional include file search path modification),
867+as <em>exactly</em>&hairsp;:
868+</p>
869+<pre class="box-out">
870+*cpp:
871+%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: }
872+%(local_includes) -D__MSVCRT_VERSION__=0x0800
873+
874+*cc1plus:
875+%(local_includes) -D__MSVCRT_VERSION__=0x0800
876+
877+*libgcc:
878+%{mthreads:-lmingwthrd} -lmingw32 -lmingwex -lmingw32 -lmingwex
879+%{static|static-libgcc:-lgcc -lgcc_eh} %{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh}
880+%{shared-libgcc:-lgcc_s -lgcc}} %{shared:-lgcc_s -lgcc}}} -lmoldname80 -lmsvcr80
881+
882+</pre>
883+<p>(and similarly, for other auxiliary &#8216;specs&#8217; files
884+relating to other non&#8209;free &#8216;C&#8217; runtime DLLs).
885+</p>
886+<p>This is better,
887+but it still leaves a significant degree of redundancy,
888+in the three definitions which <em>do</em>&hairsp; need to be modified.
889+A simple way to remove some of this redundancy,
890+<em>without</em>&hairsp; requiring any pyhsical change to
891+the originating definition,
892+as it appears in the built&#8209;in &#8216;specs&#8216;,
893+is by reformulating the amended <code>cpp</code>
894+and <code>cc1plus</code> definitions as:
895+</p>
896+<pre class="box-out">
897+*cpp:
898++ -D__MSVCRT_VERSION__=0x0800
899+
900+*cc1plus:
901++ -D__MSVCRT_VERSION__=0x0800
902+
903+</pre>
904+<p>but, unfortunately,
905+we cannot adopt a similar adjustment to remove the redundancy
906+in the modified <code>libgcc</code> definition.
907+</p>
908+<p>If we do wish to eliminate the redundancies <em>entirely</em>,&hairsp;
909+then we <em>must</em>&hairsp; modify the <code>libgcc</code> &#8216;specs&#8217;
910+string at its point of origin;
911+this implies that we <em>must</em>&hairsp; use an <em>external</em>&hairsp;
912+<code>specs</code> file,
913+in which we can make the necessary modification.
914+Thus, if we don't already have an external &#8216;specs&#8217; file,
915+we should follow the procedure described above,
916+under the heading &#8220;<a href="#prep">Preparing the GCC
917+&#8216;specs&#8217; for Customization</a>&#8221;,
918+to create one now.
919+</p>
920+<p>Once we have set up an external &#8216;specs&#8217; file,
921+such that <code>gcc</code>, and <code>g++</code>, will read it
922+instead of using their built&#8209;in &#8216;specs&#8217;,
923+we may edit it,
924+splitting the original <code>libgcc</code> definition
925+into a modified <code>libgcc</code>,
926+and a supplementary <code>libmsvcrt</code> definition, thus:
927+</p>
928+<pre class=box-out>
929+*libgcc:
930+%{mthreads:-lmingwthrd} -lmingw32 -lmingwex -lmingw32 -lmingwex
931+%{static|static-libgcc:-lgcc -lgcc_eh} %{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh}
932+%{shared-libgcc:-lgcc_s -lgcc}} %{shared:-lgcc_s -lgcc}}} %(libmsvcrt)
933+
934+*libmsvcrt:
935+-lmoldname -lmsvcrt
936+
937+</pre>
938+<p>(noting the use of <em>parentheses</em>&hairsp; in the
939+<code>%(libmsvcrt)</code> substitution field,
940+whereas <em>braces</em> are used elsewhere,
941+throughout the <code>libgcc</code> definition).
942+</p>
943+<p>Now,
944+with that single modification in place,
945+within the external <code>specs</code> file,
946+the supplementary <code>msvcr80</code> &#8216;specs&#8217; file
947+may be condensed, to nothing more than:
948+</p>
949+<pre class="box-out">
950+*cpp:
951++ -D__MSVCRT_VERSION__=0x0800
952+
953+*cc1plus:
954++ -D__MSVCRT_VERSION__=0x0800
955+
956+*libmsvcrt:
957+-lmoldname80 -lmsvcr80
958+
959+</pre>
960+<p>and Microsoft&#8217;s other non&#8209;free &#8216;C&#8217; runtime DLLs
961+may be similarly supported,
962+with suitably named copies of this supplementary &#8216;specs&#8217; file,
963+each with appropriate changes to the <code>__MSVCRT_VERSION__</code> assignment,
964+and the import libraries named in the <code>libmsvcrt</code> definition.
965+</p>
966+<div style="display: none">
967+<!-- Seemed like a good idea, but doesn't work for C++ -->
968+<h4>Consolidating Support for Non&#8209;Free Runtime Libraries</h4>
969+<p>In the preceding section,
970+we began with a naïve collection of supplementary &#8216;specs&#8217; files,
971+each of which was a mostly redundant copy of GCC&#8217;s built&#8209;in
972+&#8216;specs&#8217;, and each incorporating a minimal set of modifications,
973+specific to supporting <em>one</em>&hairsp; particular version of
974+Microsoft&#8217;s non&#8209;free &#8216;C&#8217; runtime DLLs.
975+We observed that the redundancy in this naïvely constructed collection
976+of &#8216;specs&#8217; files created an undesirable maintenance burden,
977+and we further developed the concept to eliminate the redundancy.
978+In the process,
979+we significantly reduced the size of each &#8216;specs&#8217; file,
980+while introducing a trivial dependency on a minimally&#8209;modified
981+(non&#8209;redundant) external <code>specs</code> file.
982+</p>
983+<p>In this section,
984+we will develop this concept further,
985+with a view to consolidating the entire collection of separate
986+&#8216;specs&#8217; files into the fewest practicable number,
987+while retaining the capability to arbitrarily select any one
988+of Microsoft&#8217;s non&#8209;free &#8216;C&#8217; runtime DLLs,
989+with which to link any application.
990+</p>
991+<p>Ideally,
992+we would like to consolidate all of the necessary &#8216;specs&#8217;
993+string modifications into a single,
994+<em>implicitly</em>&hairsp; loaded external <code>specs</code> file,
995+and to use a command line option to specify the particular
996+version of the &#8216;C&#8217; runtime library,
997+with which the application should be linked.
998+Unfortunately,
999+of all the predefined option keywords which <code>gcc</code> will accept,
1000+only the <code>-lfoo</code> class,
1001+(which, strictly speaking, aren&#8217;t really options anyway),
1002+seem suitable for alternative runtime library selection,
1003+and these do not appear to participate in conditional
1004+&#8216;specs&#8217; string processing.
1005+Thus,
1006+we will require custom option keywords,
1007+which <code>gcc</code> will accept <em>only</em>&hairsp; if invoked
1008+with an <em>explicitly</em>&hairsp; loaded external &#8216;specs&#8217; file,
1009+so we will be unable to realize our ideal objective;
1010+the best we are likely to achieve will be <em>one</em>&hairsp; small,
1011+<em>explicitly</em>&hairsp; loaded external &#8216;specs&#8217; file,
1012+to enable the use of custom options,
1013+(and to handle at least some of their interpretation),
1014+in conjunction with an implicitly loaded external <code>specs</code> file,
1015+modified as in the preceding section, to avoid redundancy.
1016+</p>
1017+<p>As it happens,
1018+the latter best practicable objective is entirely achievable.
1019+If we keep the external <code>specs</code> file <em>exactly</em>&hairsp;
1020+in the state as we developed it in the preceding section, but,
1021+instead of the collection of supplementary &#8216;specs&#8217; files,
1022+(one for each non&#8209;free runtime DLL),
1023+we create just <em>one</em>,&hairsp;
1024+(let&#8217;s call it <code>opt</code>),
1025+with content:
1026+</p>
1027+<pre class="box-out">
1028+*cpp:
1029++ %{msvcr*:-D__MSVCRT_VERSION__=0x0%*0}%&lt;msvcr*
1030+
1031+*cc1plus:
1032++ %{msvcr*:-D__MSVCRT_VERSION__=0x0%*0}%&lt;msvcr*
1033+
1034+*libmsvcrt:
1035+-lmoldname%{msvcr*:%* -lmsvcr%*}%{!msvcr*: -lmsvcrt}
1036+
1037+</pre>
1038+<p>then we may link our applications with <em>any</em>&hairsp;
1039+of Microsoft&#8217;s non&#8209;free &#8216;C&#8217; runtime DLLs,
1040+simply by invoking <code>gcc</code>, (or <code>g++</code>), like this:
1041+</p>
1042+<pre class="vt box-out">
1043+$ <kbd>gcc -specs=opt -msvcr&lt;N&gt; foo.c -o foo.exe</kbd>
1044+</pre>
1045+<p>(where &#8220;<code>&lt;N&gt;</code> represents the numeric identifier,
1046+within the runtime DLL name);
1047+thus, for example:
1048+</p>
1049+<pre class="vt box-out">
1050+$ <kbd>gcc -specs=opt -msvcr80 foo.c -o foo.exe</kbd>
1051+</pre>
1052+<p>would result in <code>foo.exe</code> being
1053+linked with <code>MSVCR80.DLL</code>, while:
1054+</p>
1055+<pre class="vt box-out">
1056+$ <kbd>gcc -specs=opt -msvcr120 foo.c -o foo.exe</kbd>
1057+</pre>
1058+<p>would result in linking with <code>MSVCR120.DLL</code>,
1059+and the system will automatically adapt,
1060+to accommodate linking with any other numerically identified runtime DLL,
1061+which may be available, (or may become available in the future),
1062+<em>without</em>&hairsp; requiring a separate &#8216;specs&#8217; file
1063+for each distinct DLL.
1064+</p>
1065+</div><!-- undisplayed -->
1066+</div><!-- msvcrt -->
1067+
1068+<!-- $RCSfile$: end of file -->
Show on old repository browser