Talk:Upgrading GCC
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
~~~~), and indent successive comments with colons (:).
Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.FUD
Hrm. I don't think using "FUD" to describe the previous version of this page is very chummy. I'm going to change it. Also, the references to "rebuilding everything" on the old page were for *complete assurance* of compatibility, not FUD or otherwise due to a lack of understanding. Can this page now guarantee this for those who follow the present version? --NightMonkey (talk) 22:35, 28 January 2015 (UTC)
- I actually fixed this issue. Looks like NightMonkey never clarified the acronym. --Maffblaster (talk) 23:01, 15 December 2016 (UTC)
Do we need to escape the periods?
The code currently suggests to escape the periods, like so:
root #revdep-rebuild --library 'libstdc++\.so\.5'The command works just fine without this. Wouldn't it be much user friendlier to keep it as such then?
root #revdep-rebuild --library 'libstdc++.so.5'--SwifT (talk) 18:33, 11 August 2015 (UTC)
- --library can be a regular expression, so I escaped dot to avoid ambiguity, but yes, the version without escape characters is equivalent to the escaped version. I'm going to remove the dot to cure the Leaning Toothpick Syndrome in the code. Biergaizi (talk)
- I left in the dot escapes because the manual says it interprets the argument as a BRE unless it's a full path to a library. Ideally there would be a better way to obtain the soname from the current gcc configuration using scanelf perhaps. --Ormaaj (talk) 11:01, 12 August 2015 (UTC)
- If it's a regular expression, then shouldn't it be ? - dcljr (talk) 16:18, 15 August 2016 (UTC)
root #revdep-rebuild --library 'libstdc\+\+\.so\.5' - I have verified (I think) that the older versions of revdep-rebuild really do require escaping the plus characters, otherwise no packages will be rebuilt. (When you run a recent revdep-rebuild, it says the old version is available as revdep-rebuild.sh, so I used that to test the commands.) Therefore, in my latest copyedits of the article I reintroduced the fully-escaped version where relevant (even though technically the dots don't need escaping, I did so, to match the version shown in the eselect news item about GCC 5). However, I did "de-emphasize" the escaped version in the "Short version" by moving it into running text rather than using another {RootCmd} box, because most users will probably have already upgraded to one of the post-0.3.1 versions of gentoolkit, anyway, since they've been stable for almost (or over?) a year now. - dcljr (talk) 11:09, 4 October 2017 (UTC)
C++11 and revdep-rebuild
Under "The special case C++11 (and C++14)", this article states:
- "GCC only makes C++11 ABI stability guarantees beginning with version 5.1. This means that switching (even minor) versions of gcc (say from 4.7.3 -> 4.7.4) might cause ABI breakage for binaries built from C++11 code."
And then it links to a handful of sources targeted to audiences of developers. It doesn't actually say in that section what the Gentoo user should do to avoid problems related to C++11.
Now, earlier in the article, under "ABI changes", it says:
- "If you are upgrading to GCC 4.1, or GCC 5.1, you would probably encounter ABI issues. This is also why we use the revdep-rebuild command against the libstdc++.so.5 (from GCC 3 to GCC 4.1), or libstdc++.so.6 (from GCC 4 to GCC 5.1)."
OK, but what about for changes from, say, 4.7.3 to 4.7.4 (as alluded to in the above quote), or any other 4.x to 4.y? Unless I'm more confused about this than I thought, this should also be handled with:
root #revdep-rebuild --library 'libstdc\+\+.so.6'
Right? Can someone who knows please make this more clear in the "special case C++11" section?
Also, is it crucial to do this rebuilding immediately after the switch of GCC versions? Or just when any C++11-based package has to be built (IOW, if you do any C++11's, do all of them)? Does it matter if/when you restart services (say, X)? Just curious… - dcljr (talk) 16:23, 15 August 2016 (UTC)
Packages known to need rebuilding
In the list of packages that are known to need rebuilding should we add: dev-libs/leveldb
I don't know if that's appropriate or not, but I had that problem and I've seen others in the forums have the same/similar problem:
https://forums.gentoo.org/viewtopic-t-1065516-start-0-postdays-0-postorder-asc-highlight-.html
https://forums.gentoo.org/viewtopic-t-1056646-highlight-leveldb.html
https://forums.gentoo.org/viewtopic-t-1057232-highlight-leveldb.html
Seems to be a problem between a GCC version 5 upgrade and a qtwebkit upgrade.
I don't understand more than that so far. Thanks!
Aries97 (talk) 19:13, 8 July 2017 (UTC)
MUST rebuild
The following statement is questionable:
- To be completely sure that your system is in a sane state, you must rebuild the toolchain and then world to make use of the new compiler.
I certainly don't believe it is always necessary and I have never done such instructions except when I tried a hardened toolchain once. If there is major changes, there should be a GLEP news announcement (such as the proposed PIE change).
I would like to see what Jonasstein would say to this as well. --Grknight (talk) 20:54, 4 August 2017 (UTC)
- My comment on the rebuild-all strategy:
- It takes very long to find out manually which packages need to be compiled. Then find out which were missed.
- The fast and safe way is to rebuild all on a modern computer. Bugzilla gets flooded during gcc upgrades and 99% of the problems could be solved with the complete rebuild. In an ideal world we would have of course a package manager which can handle this and rebuilds on demand.--Jonasstein (talk) 19:30, 8 August 2017 (UTC)
- I came here for the same reason as Grknight: It is ironic that after repeatedly ridiculing and dismissing the idea that you "have to rebuild everything" — even calling it FUD (spelling out the meaning of the acronym) — this article ends with the statement that "To be completely sure", you have to rebuild everything! What are readers supposed to think? Either remove this FUD-inducing statement, reword it carefully to inform readers and not scare them, or rewrite the entire article to suggest that the "rebuild-everything" approach is not so crazy after all. - dcljr (talk) 07:37, 17 August 2017 (UTC)
- What about two sections: a) one can investigate which packages need to be rebuilt (this changes and is not trivial) b) for the lazy with a recent computer (time to rebuild is less then to research and fix). We get daily reports on bugzilla because some package was not rebuilt. This is an enormous waste of manpower. So I think it is important to say: True is a, but our documentation of a may be incomplete and if a fails and you can not figure it out and document it, try b before opening a bug ticket. If the user prefers to the computer compile a night, instead of fixing all the weekend manually, there is a solution b. So the user has the choice. --Jonas Stein (talk) 19:05, 4 October 2017 (UTC)
Drop or move to another place information for old gcc versions
When visiting this page I found a bit useless to keep informing people in the "short version" about how to upgrade from gcc3... I guess nobody will try this days to update such an old system. I would remove it or, if still needed, move it to a different section (Troubleshooting?) Pacho (talk) 17:26, 19 November 2017 (UTC)
- Note that gcc-3.3.6-r1 and gcc-2.95.3-r10 are each keyworded on at least a couple of platforms in the Gentoo repository. This is prima facie evidence that some users may still need to upgrade from pre-3.4 versions. As for how many users may be in this position, I cannot say. Even if the instructions were moved elsewhere, an informative link to the instructions would still need to be provided in the short version. Would doing this really improve the article that much? - dcljr (talk) 05:29, 20 November 2017 (UTC)
- But that packages are even not supported at all... they are even hardmasked with this:
Michał Górny <mgorny@gentoo.org>, Andreas K. Hüttel <dilfridge@gentoo.org>, Matthias Maier <tamiko@gentoo.org> (21 May 2017) These old versions of toolchain packages (binutils, gcc, glibc) are no longer officially supported and are not suitable for general use. Using these packages can result in build failures (and possible breakage) for many packages, and may leave your system vulnerable to known security exploits. If you still use one of these old toolchain packages, please upgrade (and switch the compiler / the binutils) ASAP. If you need them for a specific (isolated) use case, feel free to unmask them on your system. <sys-devel/gcc-4.9 <sys-libs/glibc-2.23-r4 <sys-devel/binutils-2.28.1
- Hmm. How can
<sys-devel/gcc-4.9be hardmasked when versions 4.8.5, 4.7.4, 4.6.4, 4.5.4, 4.4.7, 4.1.2, and 3.4.6-r2 are all still marked stable on all platforms at packages.gentoo.org? (Or, I guess I mean the reverse: how can they still be marked stable when they are hardmasked for presumably good reasons?) Note that 5 earlier versions of glibc (that would fall under the mask shown above) and 2 earler versions of binutils are also marked stable on all platforms. - dcljr (talk) 22:20, 26 November 2017 (UTC)
- Hmm. How can
- Because they were stabilize long long time ago and adding a hardmask later doesn't need to move them to testing. That is the way we are using hardmasks for many other packages (for example some with security issues discovered later or packages that are treecleaned) Pacho (talk) 22:47, 26 November 2017 (UTC)
Clarify if we must or not to run revdep-rebuild
Statement "revdep-rebuild is usually only necessary when upgrading to a new major version (i.e., 3.x to 4.x, or 4.x to 5.x)" What does "usually" mean? Do we need to run it or not? For example when updating from gcc5 to gcc6. Is that optional? Pacho (talk) 17:26, 19 November 2017 (UTC)
- As you can see by looking above this section, there has already been a lot of discussion about this issue on this talk page. I and others have repeatedly asked people with better knowledge of GCC and software maintenance in general to provide better information in the article. So far, no one has taken up the challenge. (I have recently tried to improve the article in various places, but I have no real expertise in this area.) - dcljr (talk) 05:29, 20 November 2017 (UTC)
- Ah, ok, I have asked toolchain people... let's see if they can clarify this things. See you!
- https://bugs.gentoo.org/638516
- Pacho (talk) 20:40, 22 November 2017 (UTC)
List all packages to rebuild in Short version
"Short version" states only libtool as a package to manually need to rebuild, but, later, it's explained that llvm and clang also need to be rebuilt. If that is the case, I would list them in Short version, otherwise many people won't rebuilt them. Pacho (talk) 17:26, 19 November 2017 (UTC)
- The short version describes using revdep-rebuild. This approach will rebuild the packages you mention. As for the lack of clarity about when and whether this is necessary, see my other replies. - dcljr (talk) 05:29, 20 November 2017 (UTC)
Contradictory information in "Which packages are known to need a rebuild?" and next section
"Which packages are known to need a rebuild?" states that "To be completely sure that your system is in a sane state, you must rebuild the toolchain and then world to make use of the new compiler." But the next section explain that this is not needed :/
Thanks Pacho (talk) 17:26, 19 November 2017 (UTC)
- Again, see above on this talk page. There is actually disagreement as to whether, when, and which packages need rebuilding. The contradictions and inconsistencies you have pointed out are mostly the result of different users editing different parts of the article at different times. For what it's worth, I have just made revisions that affect the very text you are alluding to in this comment. - dcljr (talk) 05:29, 20 November 2017 (UTC)
New package to be rebuilt?
Should the package dev-lang/rust be included in the list of packages to be rebuilt?
--Neyuru (talk) 01:01, 24 April 2020 (UTC)
make clean
After a compiler upgrade I needed to run make clean to use compile the kernel using make menuconfig so, shouldn't this be advised on this guide? --Neyuru (talk) 22:47, 25 April 2020 (UTC)