On 13 November 2011 04:40, Gerald Pfeifer <ger...@pfeifer.com> wrote:
> On Mon, 7 Nov 2011, Jonathan Wakely wrote:
>> We currently have a broken link in the installation docs, see below.
>> I've tried to fix it, but on both Fedora 15 and Debian squeeze the
>> docs generated by "make html" do not match the online docs because of
>> a different version of makeinfo (4.13 versus 4.8 usedfor the online
>> docs).
>>
>> Can anyone with makeinfo 4.8 confirm that this fixes the broken anchor?
>>
>> Or should I just commit it as obvious and revert it if the regenerated
>> onlinedocs aren't fixed?
>
> Jonathan, I am a bit confused because if I use the online documentation
> at http://gcc.gnu.org/install/specific.html the anchor is already of the
> form "sparc-sun-solaris210", that is, without the dot, and it works just
> fine.

The list of targets at the top of the page includes
x86_64-*-solaris2.1[0-9]* which is a hyperlink to
http://gcc.gnu.org/install/specific.html#x86-64-x-solaris210

Clicking it does nothing.  It's supposed to go to this anchor:
<h3 class="heading"><a name="TOC58"></a><a
name="x86-64-x-solaris2_002e10"></a>x86_64-*-solaris2.1[0-9]*</h3>

Does clicking x86_64-*-solaris2.1[0-9]* work for you?

> On the other hand, looking at the source code your patch has not been
> applied yet.
>
> Since your patch makes things just more conservative and robust, let's
> go ahead and apply it.  Just, if there is something I missed, please
> advise. :-)

OK, I'll apply it and check the results after the docs regenerate, thanks.


> As a bit of background, sadly at one point makeinfo added transformations
> for special characters to replace them by hex values weirdly encoded;
> that is the _002e you are seeing: hex 2E, the ASCII dot.
>
> For this reason I have this in wwwdocs/bin/preprocess that takes care
> of restorting dashes and asterisks (at the price of breaking links to
> external documents, since we can only fix up what is under our control):
>
>  sed -e 's/_002d/-/g' -e 's/_002a/*/g'
>
> We might consider adding -e 's/_002e/./g', but really, just avoiding
> this altogether as your patch does, seems wiser.

Aha, that explains why when I regenerate the docs I get hundreds of
escaped characters that I don't see when looking at the onlinedocs.

Reply via email to