[v3 patch] documentation update
Phil Edwards
pedwards@disaster.jaj.com
Thu Feb 15 14:22:00 GMT 2001
Very minor and boring. Applied to the trunk.
2001-02-15 Phil Edwards <pme@sources.redhat.com>
* docs/html/configopts.html: Minor updates and typo fixes.
* docs/html/faq/index.html: Updates of the "not really bugs" list.
* docs/html/faq/index.txt: Regenerated.
Index: docs/html/configopts.html
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/docs/html/configopts.html,v
retrieving revision 1.6
diff -u -3 -p -r1.6 configopts.html
--- configopts.html 2001/02/07 00:03:20 1.6
+++ configopts.html 2001/02/15 22:19:37
@@ -66,7 +66,7 @@ options</A></H1>
I/O package (from
<A HREF=" http://sources.redhat.com/glibc/ ">glibc</A>, the
GNU C library), or 'stdio' to use a generic "C"
- abstraction. The default is 'stdio'.
+ abstraction. The default is 'stdio'.
</P>
<DT><TT>--enable-clocale </TT>
@@ -81,7 +81,7 @@ options</A></H1>
HREF=" http://sources.redhat.com/glibc/ ">glibc</A>, the GNU C
library), or 'generic' to use a generic "C"
abstraction which consists of "C" locale info.
- The default is 'generic'.
+ The default is 'generic'.
</P>
<DT><TT>--enable-long-long </TT>
@@ -98,10 +98,9 @@ options</A></H1>
<DT><TT>--enable-cheaders=OPTION </TT>
<DD><P>This allows the user to define what kind of C headers are
- used. Options are: c, c_std, and c_shadow. These correspond
- to the source directory's include/c, include/c_std, and
- include/c_shadow directories.
- The default is c_std.
+ used. Options are: c, c_std, and c_shadow. These correspond
+ to the source directory's include/c, include/c_std, and
+ include/c_shadow directories. The default is c_std.
</P>
<DT><TT>--enable-threads </TT>
@@ -151,25 +150,24 @@ options</A></H1>
flags to the compiler to use when building libstdc++. FLAGS
is a quoted string of options, like
<PRE>
- --enable-cxx-flags='-fsquangle -fvtable-gc -ansi'</PRE>
+ --enable-cxx-flags='-fvtable-gc -fomit-frame-pointer -ansi'</PRE>
Note that the flags don't necessarily have to all be -f flags,
as shown, but usually those are the ones that will make sense
for experimentation and configure-time overriding.
</P>
<P>The advantage of --enable-cxx-flags over setting CXXFLAGS in
- the 'make' environment is that, if libgcc is automatically
+ the 'make' environment is that, if files are automatically
rebuilt, the same flags will be used when compiling those files
as well, so that everything matches.
</P>
<P>Fun flags to try might include combinations of
<PRE>
-fstrict-aliasing
- -fnew-abi
- -fnew-exceptions
+ -fno-exceptions
-ffunction-sections
-fvtable-gc</PRE>
- and -fno- forms of the same. Tell us (the mailing list) if
- you discover more!
+ and opposite forms (-fno-) of the same. Tell us (the mailing
+ list) if you discover more!
</P>
<DT><TT>--enable-c-mbchar </TT>[default]
@@ -178,7 +176,7 @@ options</A></H1>
changing rapidly, and can cause problems on new platforms.
Disabling wide character specializations is useful for initial
porting steps, but builds only a subset of what is required by
- ISO. Default is on, but the <TT>--enable-c_stdio=stdio </TT>
+ ISO. Default is on, but the <TT>--enable-cstdio=stdio </TT>
option currently turns it off.
</P>
</DL>
Index: docs/html/faq/index.html
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/docs/html/faq/index.html,v
retrieving revision 1.2
diff -u -3 -p -r1.2 index.html
--- index.html 2001/01/23 17:02:27 1.2
+++ index.html 2001/02/15 22:19:37
@@ -62,8 +62,14 @@ http://gcc.gnu.org/onlinedocs/libstdc++/
<LI><A HREF="#4_2">Bugs in gcc/g++ (not libstdc++-v3)</A>
<LI><A HREF="#4_3">Bugs in the C++ language/lib specification</A>
<LI><A HREF="#4_4">Things in libstdc++ that look like bugs</A>
- <BR><A HREF="#4_4_interface">The g++-3 headers are
- <STRONG>not ours</STRONG></A>
+ <UL>
+ <LI><A HREF="#4_4_Weff">-Weffc++ complains too much</A>
+ <LI><A HREF="#4_4_rel_ops">"ambiguous overloads"
+ after including an old-style header</A>
+ <LI><A HREF="#4_4_interface">The g++-3 headers are
+ <STRONG>not ours</STRONG></A>
+ <LI><A HREF="#4_4_glibc">compilation errors from streambuf.h</A>
+ </UL>
<LI><A HREF="#4_5">Aw, that's easy to fix!</A>
</OL>
@@ -489,44 +495,66 @@ to the list</A>, Nathan Myers announced
<H2><A NAME="4_4">4.4 Things in libstdc++ that look like bugs</A></H2>
<P>There are things which are not bugs in the compiler (4.2) nor
the language specification (4.3), but aren't really bugs in
- libstdc++, either. Really!
+ libstdc++, either. Really! Please do not report these as bugs.
</P>
- <P>The biggest of these is the quadzillions of warnings about the
- library headers emitted when <TT>-Weffc++</TT> is used. Making
- libstdc++ "-Weffc++-clean" is not a goal of the project,
- for a few reasons. Mainly, that option tries to enforce
- object-oriented programming, while the Standard Library isn't
- necessarily trying to be OO. There are multiple solutions
- under discussion.
- </P>
- <P>Another is the <TT>rel_ops</TT> namespace and the template
- comparison operator functions contained therein. If they become
- visible in the same namespace as other comparison functions
- (e.g., '<TT>using</TT>' them and the <iterator> header),
- then you will suddenly be faced with huge numbers of ambiguity
- errors. This was discussed on the -v3 list; Nathan Myers
- <A HREF=" http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html ">sums
- things up here</A>.
- </P>
- <H3><A NAME="4_4_interface">The g++-3 headers are
- <EM>not ours</EM></A></H3>
- <P>If you have found an extremely broken header file which is
- causing problems for you, look carefully before submitting a
- "high" priority bug report (which you probably shouldn't
- do anyhow; see the last paragraph of the page describing
+ <A NAME="4_4_Weff">
+ <P>The biggest of these is the quadzillions of warnings about the
+ library headers emitted when <TT>-Weffc++</TT> is used. Making
+ libstdc++ "-Weffc++-clean" is not a goal of the project,
+ for a few reasons. Mainly, that option tries to enforce
+ object-oriented programming, while the Standard Library isn't
+ necessarily trying to be OO. There are multiple solutions
+ under discussion.
+ </P>
+ </A>
+ <A NAME="4_4_rel_ops">
+ <P>Another is the <TT>rel_ops</TT> namespace and the template
+ comparison operator functions contained therein. If they become
+ visible in the same namespace as other comparison functions
+ (e.g., '<TT>using</TT>' them and the <iterator> header),
+ then you will suddenly be faced with huge numbers of ambiguity
+ errors. This was discussed on the -v3 list; Nathan Myers
+ <A HREF=" http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html ">sums
+ things up here</A>.
+ </P>
+ </A>
+ <A NAME="4_4_interface"><H3>The g++-3 headers are
+ <EM>not ours</EM></H3>
+ <P>If you have found an extremely broken header file which is
+ causing problems for you, look carefully before submitting a
+ "high" priority bug report (which you probably shouldn't
+ do anyhow; see the last paragraph of the page describing
<A HREF=" http://gcc.gnu.org/gnatswrite.html ">the GCC bug database</A>).
- </P>
- <P>If the headers are in <CODE>${prefix}/include/g++-3</CODE>, then
- you are using the old libstdc++-v2 library, which is nonstandard
- and unmaintained. Do not report problems with -v2 to the -v3
- mailing list.
- </P>
- <P>Currently our header files are installed in
- <CODE>${prefix}/include/g++-v3</CODE> (see the 'v'?). This may
- change with the next release of GCC, as it may be too confusing,
- but <A HREF=" http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html ">the
- question has not yet been decided</A>.
- </P>
+ </P>
+ <P>If the headers are in <CODE>${prefix}/include/g++-3</CODE>, then
+ you are using the old libstdc++-v2 library, which is nonstandard
+ and unmaintained. Do not report problems with -v2 to the -v3
+ mailing list.
+ </P>
+ <P>Currently our header files are installed in
+ <CODE>${prefix}/include/g++-v3</CODE> (see the 'v'?). This may
+ change with the next release of GCC, as it may be too confusing,
+ but <A HREF=" http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html ">the
+ question has not yet been decided</A>.
+ </P>
+ </A>
+ <A NAME="4_4_glibc">
+ <P>If you're on a GNU/Linux system and have just upgraded to
+ glibc 2.2, but are still using gcc 2.95.2, then you should have
+ read the glibc FAQ, specifically 2.34:
+ <PRE>
+2.34. When compiling C++ programs, I get a compilation error in streambuf.h.
+
+{BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to
+apply a patch to the include files in /usr/include/g++, because the fpos_t
+type has changed in glibc 2.2. The patch is at
+ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
+ </PRE>
+ Note that 2.95.x shipped with the
+ <A HREF="#4_4_interface">old v2 library</A> which is no longer
+ maintained.
+ </P>
+ </A>
<HR>
<H2><A NAME="4_5">4.5 Aw, that's easy to fix!</A></H2>
@@ -534,8 +562,8 @@ to the list</A>, Nathan Myers announced
a working fix, then send it in! The main GCC site has a page
on <A HREF=" http://gcc.gnu.org/contribute.html ">submitting
patches</A> that covers the procedure, but for libstdc++ you
- should of course send the patch to our mailing list, not the
- GCC mailing list. The libstdc++
+ should also send the patch to our mailing list in addition to
+ the GCC patches mailing list. The libstdc++
<A HREF="../17_intro/contribute.html">contributors' page</A>
also talks about how to submit patches.
</P>
More information about the Gcc-patches
mailing list