After installing gcc-11.1.0, I find that its manpages and info documentation are inaccessible by their utilities. Commands like "man c++" or "info gcc" fail to give back anything. Using "equery f sys-devel/gcc" shows that the documentation does get installed, they just can't be retrieved by their respective utilities. This makes me wonder if storing them under a directory like "/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/" (where they are in my case) is a new change for GCC that has yet to be accounted for. Reproducible: Always Steps to Reproduce: 1. Install gcc-11.1.0 (use of the "doc" USE flag is not required) 2. Check the files exist in the "man" and "info" subdirectories under /usr/share/gcc-data/<target triple>/<version>/ 3. Try finding these files via "man gcc" or "info gcc" Actual Results: Both "man" and "info" insist the documentation for GCC does not exist. Expected Results: Both "man" and "info" should display the documentation that comes with GCC.
Configuration files that adjust MANPATH and INFOPATH accordingly are installed into /etc/env.d/gcc. I guess the reporter overrides these environment variables in his personal .bashrc, .bash_profile or similar files.
I have never once modified my MANPATH or INFOPATH settings, and I just double-checked my ~/.bashrc to make sure it wasn't calling on something that does change it. I promise you that the reporter has never once in her life fiddled with how "man" or "info" find their documentation.
I just realized that maybe I should check the aforementioned MANPATH and INFOPATH, and it turns out they were looking for a non-existent old version of GCC. Doing the whole "source /etc/profile" thing updated those variables as you'd expect. In the future, it would be nice if emerge gave a post-install reminder to refresh these variables, since I never would've expected man and info to rely on environment variables, of all things, to function as their documentation databases. I actually tried to find some tool to manually regenerate man's database before filing a report, and my search results never brought this up.
(In reply to rnddim from comment #0) > After installing gcc-11.1.0, I find that its manpages and info documentation > are inaccessible by their utilities. Commands like "man c++" or "info gcc" > fail to give back anything. > > Using "equery f sys-devel/gcc" shows that the documentation does get > installed, they just can't be retrieved by their respective utilities. This > makes me wonder if storing them under a directory like > "/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/" (where they are in my > case) is a new change for GCC that has yet to be accounted for. > > Reproducible: Always > > Steps to Reproduce: > 1. Install gcc-11.1.0 (use of the "doc" USE flag is not required) > 2. Check the files exist in the "man" and "info" subdirectories under > /usr/share/gcc-data/<target triple>/<version>/ > 3. Try finding these files via "man gcc" or "info gcc" > Actual Results: > Both "man" and "info" insist the documentation for GCC does not exist. > > Expected Results: > Both "man" and "info" should display the documentation that comes with GCC. man c++ Kein Handbucheintrag für c++ vorhanden man gcc works info works for both
Sorry, my original comment had a typo there. It should've read "man g++" instead of c++.
gcc switch already prints the suggestion to source /etc/profile: # gcc-config 48 * Switching native-compiler to x86_64-pc-linux-gnu-12.0.0 ... >>> Regenerating /etc/ld.so.cache... [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * . /etc/profile Unfortunately it does not get piped to `einfo` to get printed after full merge session. I'd like gcc-config to provide stable directory for man and info files, e.g. instead of current: /etc/env.d/04gcc-x86_64-pc-linux-gnu # Autogenerated by 'gcc-config'. GCC_SPECS="" MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/12.0.0/man" INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/12.0.0/info" something like /etc/env.d/04gcc-x86_64-pc-linux-gnu # Autogenerated by 'gcc-config'. GCC_SPECS="" MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/current/man" INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/current/info" where /usr/share/gcc-data/x86_64-pc-linux-gnu/current/{man,info} is maintained by gcc-config.
for other multislot packages, we install the man & info pages with version suffixes. for example, autoconf & automake are using -$SLOT suffixes. we should look at doing the same for binutils & gcc. this would avoid the need for constant env shuffling with the docs, and make it so people could easily flip between diff versions documentation. e.g. they can run `man gcc-11` and `man gcc-10` in diff windows. renaming man pages is trivial, so we should start there. info pages have long given us trouble due to self referencing nodes needing renaming (e.g. autoconf has literal "autoconf" nodes that look for autoconf.info that we have to rewrite to "autoconf-$SLOT" everywhere so as to not break it).
(In reply to SpanKY from comment #7) > for other multislot packages, we install the man & info pages with version > suffixes. for example, autoconf & automake are using -$SLOT suffixes. > > we should look at doing the same for binutils & gcc. this would avoid the > need for constant env shuffling with the docs, and make it so people could > easily flip between diff versions documentation. e.g. they can run `man > gcc-11` and `man gcc-10` in diff windows. > > renaming man pages is trivial, so we should start there. info pages have > long given us trouble due to self referencing nodes needing renaming (e.g. > autoconf has literal "autoconf" nodes that look for autoconf.info that we > have to rewrite to "autoconf-$SLOT" everywhere so as to not break it). i don't believe that to be the right fix as it introduces gentoo-specific behavior. IMO, we should promote the selected config into a more permanent location in *PATH. info viewers prefer sibling files to path (by default) on top of that, so they should behave well for our use case.
