From: Paolo Carlini <pcarlini@suse.de>
To: Gerald Pfeifer <gerald@pfeifer.com>
Cc: libstdc++@gcc.gnu.org, gcc@gcc.gnu.org
Subject: Re: http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help
Date: Sun, 23 Mar 2008 20:59:00 -0000 [thread overview]
Message-ID: <47E6AD83.3090904@suse.de> (raw)
In-Reply-To: <alpine.LSU.1.00.0803231712350.22304@acrux.dbai.tuwien.ac.at>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
Hi Gerald,
> Working on the link consistency of the http://gcc.gnu.org, I ran into
> a couple of links on the libstdc++ side that are in need of a bit love.
> It would be great could one of you libstdc++ guys look into those.
>
Should be all fixed with the below, applied mainline and 4_3-branch.
Thanks for the heads up!
Paolo.
///////////////////
[-- Attachment #2: CL_doc --]
[-- Type: text/plain, Size: 280 bytes --]
2008-03-23 Paolo Carlini <pcarlini@suse.de>
* doc/xml/faq.xml: Fix various links.
* doc/xml/api.xml: Likewise.
* doc/xml/manual/parallel_mode.xml: Likewise.
* doc/html/faq.html: Regenerate.
* doc/html/api.html: Likewise.
* doc/html/manual/bk01pt12ch31s03.html: Likewise.
[-- Attachment #3: patch_doc --]
[-- Type: text/plain, Size: 5587 bytes --]
Index: doc/xml/faq.xml
===================================================================
--- doc/xml/faq.xml (revision 133462)
+++ doc/xml/faq.xml (working copy)
@@ -130,8 +130,8 @@
</question>
<answer id="a-how">
<para>
- Here is <ulink url="../17_intro/contribute.html">a page devoted to
- this topic</ulink>. Subscribing to the mailing list (see above, or
+ Here is <link linkend="appendix.contrib">a page devoted to
+ this topic</link>. Subscribing to the mailing list (see above, or
the homepage) is a very good idea if you have something to
contribute, or if you have spare time and want to
help. Contributions don't have to be in the form of source code;
@@ -400,7 +400,7 @@
<para>
If the only functions from <filename>libstdc++.a</filename>
which you need are language support functions (those listed in
- <ulink url="../18_support/howto.html">clause 18</ulink> of the
+ <link linkend="manual.support">clause 18</link> of the
standard, e.g., <function>new</function> and
<function>delete</function>), then try linking against
<filename>libsupc++.a</filename>, which is a subset of
@@ -785,13 +785,13 @@
reason is that the state flags are <emphasis>not</emphasis> cleared
on a successful call to open(). The standard unfortunately did
not specify behavior in this case, and to everybody's great sorrow,
- the <ulink url="../ext/howto.html#5">proposed LWG resolution in
- DR #22</ulink> is to leave the flags unchanged. You must insert a call
+ the <link linkend="manual.intro.status.bugs">proposed LWG resolution in
+ DR #22</link> is to leave the flags unchanged. You must insert a call
to <function>fs.clear()</function> between the calls to close() and open(),
and then everything will work like we all expect it to work.
<emphasis>Update:</emphasis> for GCC 4.0 we implemented the resolution
- of <ulink url="../ext/howto.html#5">DR #409</ulink> and open() now calls
- <function>clear()</function> on success!
+ of <link linkend="manual.intro.status.bugs">DR #409</link> and open()
+ now calls <function>clear()</function> on success!
</para>
</answer>
</qandaentry>
@@ -895,7 +895,7 @@
<para>
More information, including how to optionally enable/disable the
checks, is available
- <ulink url="../19_diagnostics/howto.html#3">here</ulink>.
+ <link linkend="manual.diagnostics.concept_checking">here</link>.
</para>
</answer>
</qandaentry>
@@ -940,13 +940,13 @@
<para>
A few people have reported that the standard containers appear
to leak memory when tested with memory checkers such as
- <ulink url="http://developer.kde.org/~sewardj/">valgrind</ulink>.
+ <ulink url="http://valgrind.org/">valgrind</ulink>.
The library's default allocators keep free memory in a pool
for later reuse, rather than returning it to the OS. Although
this memory is always reachable by the library and is never
lost, memory debugging tools can report it as a leak. If you
want to test the library for memory leaks please read
- <ulink url="../debug.html#mem">Tips for memory leak hunting</ulink>
+ <link linkend="debug.memory">Tips for memory leak hunting</link>
first.
</para>
</answer>
@@ -961,7 +961,7 @@
<answer id="a-list_size_on">
<para>
See
- the <ulink url="../23_containers/howto.html#6">Containers</ulink>
+ the <link linkend="manual.containers">Containers</link>
chapter.
</para>
</answer>
@@ -981,7 +981,7 @@
patches</ulink> that covers the procedure, but for libstdc++ you
should also send the patch to our mailing list in addition to
the GCC patches mailing list. The libstdc++
- <ulink url="../17_intro/contribute.html">contributors' page</ulink>
+ <link linkend="appendix.contrib">contributors' page</link>
also talks about how to submit patches.
</para>
<para>
@@ -1237,8 +1237,8 @@
The copy will take O(n) time and the swap is constant time.
</para>
<para>
- See <ulink url="../21_strings/howto.html#6">Shrink-to-fit
- strings</ulink> for a similar solution for strings.
+ See <link linkend="strings.string.shrink">Shrink-to-fit
+ strings</link> for a similar solution for strings.
</para>
</answer>
</qandaentry>
Index: doc/xml/api.xml
===================================================================
--- doc/xml/api.xml (revision 133462)
+++ doc/xml/api.xml (working copy)
@@ -15,7 +15,7 @@
2008
</year>
<holder>
- <ulink url="http://fsf.org">FSF
+ <ulink url="http://www.fsf.org/">FSF
</ulink>
</holder>
</copyright>
Index: doc/xml/manual/parallel_mode.xml
===================================================================
--- doc/xml/manual/parallel_mode.xml (revision 133462)
+++ doc/xml/manual/parallel_mode.xml (working copy)
@@ -116,7 +116,7 @@
<para>
To use the libstdc++ parallel mode, compile your application with
the compiler flag <constant>-D_GLIBCXX_PARALLEL -fopenmp</constant>. This
- will link in <code>libgomp</code>, the GNU OpenMP <ulink url="http://gcc.gnu.org/onlinedocs/libgomp">implementation</ulink>,
+ will link in <code>libgomp</code>, the GNU OpenMP <ulink url="http://gcc.gnu.org/onlinedocs/libgomp/">implementation</ulink>,
whose presence is mandatory. In addition, hardware capable of atomic
operations is mandatory. Actually activating these atomic
operations may require explicit compiler flags on some targets
next prev parent reply other threads:[~2008-03-23 19:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-23 17:23 Gerald Pfeifer
2008-03-23 20:59 ` Paolo Carlini [this message]
2008-03-24 16:25 ` Benjamin Kosnik
2008-04-07 0:06 ` Gerald Pfeifer
2008-04-09 21:59 ` Benjamin Kosnik
2008-04-12 23:25 ` Gerald Pfeifer
2008-04-15 21:30 ` Gerald Pfeifer
2008-04-18 17:22 ` Benjamin Kosnik
2008-04-18 16:46 ` Benjamin Kosnik
2008-05-24 16:47 ` Gerald Pfeifer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E6AD83.3090904@suse.de \
--to=pcarlini@suse.de \
--cc=gcc@gcc.gnu.org \
--cc=gerald@pfeifer.com \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).