• R/O
  • HTTP
  • SSH
  • HTTPS

website: Commit

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


Commit MetaInfo

Revision515a8fd24c1a098a8aaa9386e81d11bf1013f238 (tree)
Zeit2022-01-01 04:39:45
AutorKeith Marshall <keith@user...>
CommiterKeith Marshall

Log Message

Publish GCC include file search path HOWTO.

* isystem.html: New file; adapted from original Drupal content, this
describes the GCC include file search mechanism, and offers advice on
installation of third party header files, to take best advantage of
this search mechanism.

Ändern Zusammenfassung

Diff

--- /dev/null
+++ b/isystem.html
@@ -0,0 +1,542 @@
1+<!DOCTYPE HTML><!--
2+ *
3+ * isystem.html
4+ *
5+ * HOWTO establish the search path for system header files, which are
6+ * to be included when compiling code using the MinGW GCC compilers.
7+ *
8+ *
9+ * $Id$
10+ *
11+ * Written by Keith Marshall <keith@users.osdn.me>
12+ * Copyright (C) 2008, 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+ * &#8209; non-breaking hyphen
47+ * &#8216; typographic left (opening) single quote
48+ * &#8217; typographic apostrophe/right (closing) single quote
49+ * &#8220; typographic left (opening) double quote
50+ * &#8221; typographic right (closing) double quote
51+ *
52+-->
53+<script class="masthead">
54+/* Script fragment, to assign titles specific to this page; this is
55+ * encapsulated within the "masthead", where such titles are displayed,
56+ * to ensure that whatever page content may follow will be correctly
57+ * positioned, relative to the masthead content.
58+ */
59+ set_page("title", "MinGW Compiler Suite User Guide");
60+ set_page("subtitle",
61+ "HOWTO Specify the Include File Search Path for use with MinGW Compilers"
62+ );
63+</script><!-- masthead -->
64+<div class="masthead" style="display: none">
65+<p class="byline">Posted: 21-Nov-2008, by Keith; Last Update: 22-Nov-2021</p>
66+</div><!-- masthead -->
67+<div class="overlapped" id="introduction">
68+<h3>Introduction</h3>
69+<p>This Mini&#8209;HOWTO answers the question:
70+<em>&#8220;Why can&#8217;t the MinGW compilers find
71+my project&#8217;s header files?&#8221;</em>
72+</p>
73+<p>Prior to the publication of the <em>GCC&#8209;7</em> documentation,
74+(when the wording changed, to provide only a brief outline of
75+<a href="#default-search">the identification method described below</a>),
76+the <a rel="noopener noreferrer" target="_blank"
77+ href="https://gcc.gnu.org/onlinedocs/gcc-3.4.5/cpp/index.html#Top">CPP Section</a>
78+of the <a rel="noopener noreferrer" target="_blank"
79+ href="https://gcc.gnu.org/onlinedocs/index.html#dir">GCC Manual</a>
80+indicated that header files may be located in
81+<a rel="noopener noreferrer" target="_blank"
82+ href="https://gcc.gnu.org/onlinedocs/gcc-3.4.5/cpp/Search-Path.html#Search-Path"
83+>the following directories</a>:&ndash;
84+</p>
85+<div class="box-out">
86+<p>On a normal Unix system, if you do not instruct it otherwise,
87+[GCC] will look for headers requested with
88+<code>#include</code>&nbsp;<code>&lt;file&gt;</code> in:
89+</p><pre>
90+ /usr/local/include
91+ libdir/gcc/target/version/include
92+ /usr/target/include
93+ /usr/include
94+</pre>
95+<p>For <code>C++</code> programs,
96+it will also look in <code>/usr/include/g++-v3</code>, first.
97+</p></div>
98+<p>Of course, the
99+<a rel="noopener noreferrer" target="_blank"
100+ href="https://osdn.net/projects/mingw/releases/p15691"
101+>MinGW ports of GCC</a>
102+target Microsoft&#8217;s Windows system,
103+which is <em><strong>not</strong></em>
104+a <em>&#8220;normal UNIX system&#8221;</em>.
105+Nevertheless, many users,
106+particularly those coming from a UNIX or GNU/Linux background,
107+and especially when they use MSYS to emulate a UNIX file system model
108+on their MS&#8209;Windows hosts,
109+are surprised to find that MinGW,
110+using its default configuration,
111+does <em><strong>not</strong></em> automatically
112+search for header files in these directories.
113+</p>
114+</div><!-- introduction -->
115+<div class="overlapped" id="default-search">
116+<h3>Identifying MinGW&#8217;s Default Include Path</h3>
117+<p>So,
118+if MinGW compilers don&#8217;t search in these <em>&#8220;normal&#8221;</em> directories,
119+where <em><strong>do</strong></em> they search?
120+</p>
121+<p>Before answering this,
122+it may be useful to understand <em>why</em>
123+the MinGW compilers do not search in these directories.
124+Firstly, on a native MS&#8209;Windows host,
125+these directories do not typically exist;
126+the nature of the file system,
127+with multiple distinct roots
128+distributed over multiple distinctly named devices,
129+means that such path names would be ambiguous.
130+Secondly, since MinGW itself is <em>not</em> a suite of MSYS applications,
131+even if such directories are created in the MSYS environment,
132+being <em>native MS&#8209;Windows</em> applications,
133+the MinGW compilers would have no means to locate them.
134+</p>
135+<p>Thus,
136+to avoid imposing draconian restrictions on how users install MinGW,
137+the maintainers have chosen to adopt a restricted search paradigm,
138+which is determined on the basis of where MinGW is itself installed.
139+The actual search path,
140+for any specific installation of MinGW may be determined,
141+by running the compiler itself,
142+with the &#8216;<code>-v</code>&#8217; option;
143+typically, for a MinGW&#8209;GCC installation in <code>C:\MinGW</code>,
144+we might see something similar to the following,
145+from (the now dated, but nonetheless still typical)
146+MinGW&#8209;GCC&#8209;3.4.5:&ndash;
147+</p>
148+<pre class="vt box-out">
149+$ <kbd>touch foo.c bar.cpp</kbd>
150+$ <kbd>gcc -v -c foo.c</kbd>
151+:
152+#include &quot;...&quot; search starts here:
153+#include &lt;...&gt; search starts here:
154+ c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include
155+ c:/mingw/bin/../lib/gcc/mingw32/3.4.5/include
156+End of search list.
157+:
158+
159+$ <kbd>g++ -v -c bar.cpp</kbd>
160+:
161+#include &quot;...&quot; search starts here:
162+#include &lt;...&gt; search starts here:
163+ c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
164+ c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
165+ c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
166+ c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include
167+ c:/mingw/bin/../lib/gcc/mingw32/3.4.5/include
168+End of search list.
169+:
170+</pre>
171+<p>This raw&#8209;format output, as displayed by the compilers,
172+may be difficult for human readers to interpret.
173+Thus, it may be helpful to reduce it to canonical path forms:&ndash;
174+</p>
175+<pre class="vt box-out">
176+$ <kbd>gcc -v -c foo.c 2&gt;&amp;1 | sed ':1;s,/[^/.][^/]*/\.\./,/,;t 1'</kbd>
177+:
178+#include &quot;...&quot; search starts here:
179+#include &lt;...&gt; search starts here:
180+ c:/mingw/include
181+ c:/mingw/lib/gcc/mingw32/3.4.5/include
182+End of search list.
183+:
184+
185+$ <kbd>g++ -v -c bar.cpp 2&gt;&amp;1 | sed ':1;s,/[^/.][^/]*/\.\./,/,;t 1'</kbd>
186+:
187+#include &quot;...&quot; search starts here:
188+#include &lt;...&gt; search starts here:
189+ c:/mingw/include/c++/3.4.5
190+ c:/mingw/include/c++/3.4.5/mingw32
191+ c:/mingw/include/c++/3.4.5/backward
192+ c:/mingw/include
193+ c:/mingw/lib/gcc/mingw32/3.4.5/include
194+End of search list.
195+:
196+</pre>
197+</div><!-- default-search -->
198+<div class="overlapped" id="other-defaults">
199+<h3>Other Directories Searched by Default</h3>
200+<p>The minimal list of directories,
201+identified as described above,
202+specifies the <em><strong>only</strong></em> locations
203+which will be searched <em><strong>by default</strong></em>,
204+for system header files,
205+or for headers associated with user installed libraries;
206+however, there is <em><strong>one</strong></em> exception.
207+Astute readers may have noticed that
208+the include file search path is itemised in a pair of sequential lists,
209+with the second being concatenated to the first; however, the first,
210+identified as the
211+<code>#include</code>&nbsp;<code>&quot;...&quot;</code>&nbsp;<code>search</code>
212+list appears to be empty.
213+In reality, this apparent emptiness may be misleading;
214+unless the user specifies the &#8216;<code>-I-</code>&#8217; option
215+when invoking GCC, this list contains <em>exactly</em> one directory:
216+the directory in which the source file containing the
217+<code>#include</code>&nbsp;<code>&quot;file&quot;</code> directive resides.
218+</p>
219+<p>Notice that this one additional directory
220+is <em><strong>not</strong></em> searched for headers specified
221+with the <code>#include</code>&nbsp;<code>&lt;file&gt;</code> form of
222+the <code>#include</code> directive;
223+it applies only for those headers specified using
224+the <code>#include</code>&nbsp;<code>&quot;file&quot;</code> form of the directive.
225+Also note that the location of this additional directory is not fixed;
226+it is dependent on the location of the source file being compiled,
227+and, while unique for each individual source file,
228+it may vary even within the compilation scope for any project,
229+<em>and even within the scope of a single translation unit</em>,
230+if multiple source files are distributed among different directories
231+in the project&#8217;s source hierarchy.
232+</p>
233+<p>To clarify this point,
234+let us consider a trivial example.
235+Suppose that we have a small project,
236+which provides all of it&#8217;s sources in a single directory;
237+among them we might have:&ndash;
238+</p>
239+<pre class="box-out">
240+~/src
241+ :
242+ :--- bar.h
243+ :
244+ :--- foo.c
245+ :--- foo.h
246+ :
247+</pre>
248+<p>Further suppose that the file, <code>foo.c</code>,
249+includes the project&#8209;local header, <code>foo.h</code>:&ndash;
250+</p>
251+<pre class="box-out">
252+/* foo.c
253+ */
254+ :
255+#include &quot;foo.h&quot;
256+ :
257+</pre>
258+<p>and that <code>foo.h</code>, in turn,
259+includes <code>bar.h</code>:&ndash;
260+</p>
261+<pre class="box-out">
262+/* foo.h
263+ */
264+ :
265+#include &quot;bar.h&quot;
266+ :
267+</pre>
268+<p>With this arrangement,
269+we may create a build directory which is a sibling of <code>src</code>,
270+and with that as current directory,
271+we may compile <code>foo.c</code>:&ndash;
272+</p>
273+<pre class="vt box-out">
274+$ <kbd>mkdir ~/build</kbd>
275+$ <kbd>cd ~/build</kbd>
276+$ <kbd>gcc -c ../src/foo.c</kbd>
277+$
278+</pre>
279+<p>and we might have every expectation that it will compile correctly;
280+it certainly should have no problem finding the pair of header files,
281+<code>foo.h</code> and <code>bar.h</code>.
282+</p>
283+<p>Now, suppose that the project grows
284+to such a size that we decide to separate our headers
285+into a subdirectory of <code>src</code>:&ndash;
286+</p>
287+<pre class="box-out">
288+~/src
289+ :
290+ :--- foo.c
291+ :
292+ :--- hdr
293+ : :
294+ : :--- bar.h
295+ : :--- foo.h
296+ : :
297+</pre>
298+<p>After making this rearrangement,
299+if we again try to compile <code>foo.c</code>,
300+we will likely see errors resulting from the failure
301+to locate the header file <code>foo.h</code>:&ndash;
302+</p>
303+<pre class="vt box-out">
304+$ <kbd>gcc -c ../src/foo.c</kbd>
305+../src/foo.c:3:17: foo.h: No such file or directory
306+ :
307+$
308+</pre>
309+<p>To correct this, we must also modify <code>foo.c</code>,
310+to reflect the relocation of the header files:&ndash;
311+</p>
312+<pre class="box-out">
313+/* foo.c
314+ */
315+ :
316+#include &quot;hdr/foo.h&quot;
317+ :
318+</pre>
319+<p>and this should be sufficient to again let us compile
320+<code>foo.c</code> successfully:&ndash;
321+</p>
322+<pre class="vt box-out">
323+$ <kbd>gcc -c ../src/foo.c</kbd>
324+$
325+</pre>
326+<p> Note here,
327+that we did <em><strong>not</strong></em> make any corresponding change
328+in <code>bar.h</code>; that would have been wrong!
329+The rule is that, in any <code>#include</code> directive of the form:&ndash;
330+</p>
331+<pre class="box-out">#include &quot;path/file&quot;</pre>
332+<p><code>path</code> must be a <em><strong>relative</strong></em> path,
333+and it must be relative to the directory in which the file containing
334+the pertinent <code>#include</code> directive is itself located.
335+In our example,
336+since <code>foo.h</code> and <code>bar.h</code> are still
337+in the same directory,
338+searches for files included by either will commence in that same directory.
339+If we had changed <code>foo.h</code>,
340+in a manner similar to the change we made in <code>foo.c</code>,
341+then <code>foo.h</code> would have attempted
342+to <code>#include</code> the file <code>~/src/hdr/hdr/bar.h</code>,
343+instead of the intended <code>~/src/hdr/bar.h</code>.
344+</p>
345+</div><!-- other-defaults -->
346+<div class="overlapped" id="extra-includes">
347+<h3>Including Headers from Directories which are Not Searched by Default</h3>
348+<p>While the default header search paths may suffice
349+for many simple projects,
350+as project complexity grows,
351+it will often become more convenient to collect header files into
352+a central directory which is <em><strong>not</strong></em> in
353+the default search path;
354+this is particularly true of projects which provide,
355+and possibly install,
356+one or more function libraries,
357+either exclusively for their own use,
358+or maybe even for general use by other projects.
359+In such cases,
360+GCC must be <em><strong>explicitly</strong></em> notified,
361+by specifying appropriate command line options,
362+to identify the additional directories in which to search.
363+</p>
364+<p>The relevant sections of
365+<a rel="noopener noreferrer" target="_blank"
366+ href="https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#Preprocessor-Options"
367+>the GCC Manual</a>,
368+and its associated C preprocessor manual,
369+<a rel="noopener noreferrer" target="_blank"
370+ href="https://gcc.gnu.org/onlinedocs/cpp/Invocation.html#Invocation"
371+>document several options</a>,
372+which may be used to specify directories to search for header files;
373+of these,
374+the most widely used is the
375+<code>-I</code>&nbsp;<code><em>dir</em></code> option.
376+As an example of its use, let us reconsider the previous example,
377+with the project source files organised within the hierarchy:&ndash;
378+</p>
379+<pre class="box-out">
380+~/src
381+ :
382+ :--- foo.c
383+ :
384+ :--- hdr
385+ : :
386+ : :--- bar.h
387+ : :--- foo.h
388+ : :
389+</pre>
390+<p>but this time,
391+we will <em><strong>not</strong></em> adapt <code>foo.c</code>
392+to locate <code>foo.h</code> using the default include file search path:&ndash;
393+</p>
394+<pre class="box-out">
395+/* foo.c
396+ */
397+ :
398+#include &quot;foo.h&quot;
399+ :
400+</pre>
401+<p>As we saw previously,
402+if we try to compile this unmodified <code>foo.c</code>,
403+without explicitly specifying any header search path,
404+the compilation will fail:&ndash;
405+</p>
406+<pre class="vt box-out">
407+$ <kbd>gcc -c ../src/foo.c</kbd>
408+../src/foo.c:3:17: foo.h: No such file or directory
409+ :
410+$
411+</pre>
412+<p>Previously,
413+we corrected this failure by modifying <code>foo.c</code>,
414+to bring <code>foo.h</code> into the
415+default <code>#include</code>&nbsp;<code>&quot;...&quot;</code> search path.
416+This time, we will correct it, not by modifying <code>foo.c</code>,
417+but by <em><strong>explicitly</strong></em> adding our project&#8217;s
418+local <code>hdr</code> directory to the search path,
419+when we invoke GCC to compile <code>foo.c</code>:&ndash;
420+</p>
421+<pre class="vt box-out">
422+$ <kbd>gcc -I ../src/hdr -c ../src/foo.c</kbd>
423+$
424+</pre>
425+<p>which, we may observe, again results in successful compilation.
426+</p>
427+</div><!-- extra-includes -->
428+<div class="overlapped" id="third-party">
429+<h3>Using Headers Provided with Locally Installed External Libraries</h3>
430+<p>Many projects have dependencies on external libraries,
431+which are <em>not</em> provided by a standard MinGW installation.
432+Users who wish to build the applications provided by such projects
433+must first install the appropriate prerequisite libraries.
434+Such libraries are referred to as
435+<em>&#8220;locally installed libraries&#8221;</em>,
436+and they must be installed such that MinGW&#8217;s GCC can readily
437+locate both the libraries themselves,
438+<em>and</em> any header files installed as prerequisites
439+for specifying the interface to the library functions.
440+</p>
441+<p>The installation of
442+such external libraries may be viewed as a challenge,
443+for some users.
444+Typically,
445+and particularly in the case of library packages
446+originally developed for Unix&#8209;like platforms,
447+such libraries would be installed into
448+the <code>/usr/local/...</code> directory hierarchy.
449+However, as we have seen above,
450+MinGW&#8217;s GCC
451+does not consider any such hierarchy in its default search paths,
452+either for header files, or for libraries.
453+Thus, the challenge is to choose an installation strategy
454+which achieves a satisfactory compromise between:&ndash;
455+</p>
456+<ol>
457+<li>Installing directly into MinGW&#8217;s own standard
458+ <code>&lt;mingw-root&gt;/include</code>
459+ and <code>&lt;mingw-root&gt;/lib</code> directory hierarchies;
460+ this offers the advantage that the libraries,
461+ and their associated header files,
462+ are placed directly into MinGW&#8209;GCC&#8217;s default search paths,
463+ so there is no additional burden placed on the user,
464+ to add additional <code>-I</code>&nbsp;<code><em>dir</em></code> options,
465+ throughout the build systems of any project using an external library.
466+ However, while perhaps being the simplest option,
467+ this strategy is not without its disadvantages:&ndash;
468+ <ul style="margin: 0.3em 0 0 -1em; list-style: disc">
469+ <li>The external library components are intermingled,
470+ within the file system hierarchy,
471+ with MinGW&#8217;s own standard components;
472+ it may not be straightforward to segregate them later,
473+ should this ever be necessary.
474+ </li>
475+ <li>Should the user wish to maintain <em>side&#8209;by&#8209;side</em>
476+ MinGW installations, at differing release point versions, say,
477+ then the external library installations will need to be duplicated,
478+ within each of the separate MinGW installation hierarchies.
479+ </li>
480+ <li>If the MinGW installation hierarchy is purged,
481+ in preparation for a clean re&#8209;installation,
482+ then any locally installed external libraries will also be purged,
483+ and if subsequently needed, will have to be reinstalled.
484+ </li>
485+</ul>
486+<li>Creating a separate directory hierarchy,
487+ into which all external library packages are installed;
488+ this mitigates the disadvantages of option (1),
489+ but introduces its own drawbacks:&ndash;
490+ <ul style="margin: 0.3em 0 0 -1em; list-style: disc">
491+ <li>The header files and libraries are no longer in
492+ MinGW GCC&#8217;s default search paths;
493+ thus the user <em><strong>must</strong></em> make provision
494+ to pass the appropriate <code>-I</code>&nbsp;<code><em>dir</em></code>,
495+ (and associated <code>-L</code>&nbsp;<code><em>dir</em></code>),
496+ options to GCC, through his own projects&#8217; build systems.
497+ (This may be mitigated, in turn, by customising the
498+ <a target="_blank" href="index.html?page=gccspecs.html"
499+ ><em>GCC Specs File</em></a>,
500+ to supply the necessary options <em>automatically</em>,
501+ for <em>all</em> invocations of GCC,
502+ or by appropriately defining GCC&#8217;s
503+ <a rel="noopener noreferrer" target="_blank"
504+ href="http://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html#Environment-Variables"
505+ ><em>CPATH and related environment variables</em></a>).
506+ </li>
507+ <li>Although now segregated from the MinGW standard library
508+ and header components, all external library packages are still intermixed,
509+ one with another, in a common installation hierarchy; nonetheless,
510+ this is often considered to be an acceptable compromise.
511+ </li>
512+</ul></li>
513+<li>As a variation on option (2),
514+ create a separate directory hierarchy,
515+ for <em>each</em> and <em>every individual</em> external library package
516+ to be locally installed;
517+ this mitigates all of the disadvantages of option (1),
518+ and the package intermixing of option (2),
519+ but it incurs an alternative penalty:&ndash;
520+ <ul style="margin: 0.3em 0 0 -1em; list-style: disc">
521+ <li>As with option (2),
522+ appropriate <code>-I</code>&nbsp;<code><em>dir</em></code>
523+ and <code>-L</code>&nbsp;<code><em>dir</em></code> options
524+ <em>must</em> be added to each GCC invocation; however,
525+ whereas option (2) requires only one additional path of each type,
526+ this option requires an additional one of each type,
527+ for <em>each</em> and <em>every</em> external library to be deployed.
528+ (While this may still be achieved by appropriate customisation of the
529+ <a target="_blank" href="index.html?page=gccspecs.html#isystem"
530+ ><em>GCC Specs File</em></a>,
531+ or by appropriately specifying the
532+ <a rel="noopener noreferrer" target="_blank"
533+ href="http://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html#Environment-Variables"
534+ ><em>CPATH and related environment variables</em></a>,
535+ the additional complexity, and maintenance overhead,
536+ may be considered unacceptable to many users).
537+ </li>
538+</ul>
539+</li></ol>
540+</div><!-- third-party -->
541+
542+<!-- $RCSfile$: end of file -->
Show on old repository browser