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.
