To improve user-friendliness a bit, I think the following should be added to gcc-3.4.x ebuilds. ################################################################ pkg_postinst() { einfo einfo "If you did not already read it, there is a HOWTO about" einfo "upgrading to GCC 3.4, from older versions, on Gentoo systems," einfo "which you should readily read, as there is quite a few steps" einfo "you have to follow, to avoid many potential and actual problems." einfo "This HOWTO is located on the Gentoo Linux Wiki, at the following URL:" einfo "http://gentoo-wiki.com/HOWTO_Migrate_to_GCC_3.4" einfo } ################################################################ Reproducible: Always Steps to Reproduce:
I don't really think that we should be linking unofficial docs - over which Gentoo has no control - in ebuilds...
(In reply to comment #1) > I don't really think that we should be linking unofficial docs - over which > Gentoo has no control - in ebuilds... The HOWTO is licensed under the GNU Free Documentation License (http://gentoo-wiki.com/Gentoo_Linux_Wiki:General_disclaimer). If linking to an unofficial website is a problem, the HOWTO might be integrated into the official Gentoo documentation. I think, however, the Gentoo Linux Wiki is a pretty popular website inside the Gentoo community... (to the point I didn't even think for a second, it wasn't, in some way, 'official'... if the einfo I wrote is used, there should indeed be a notice of the fact this website is not official). There is, of course, a need of control, to avoid users having problems if the HOWTO is someday edited by someone with bad purposes, but those users, without proper documentation, might certainly break their system anyway, if they upgrade to gcc-3.4 without doing anything else... (yeah, gcc-3.4 is still in testing, use it at your own risk, you should always read the manual, etc. but it doesn't mean we always do that, even knowing it perfectly, so a little notice from the ebuild would be nice ^_^) There don't seem to be any gcc-3.4 migration tutorial in the official Gentoo forum... if integrating the HOWTO to the official Gentoo documentation might take to much time (I don't know how they handle things), a well known user might start a thread about gcc-3.4 migration, quoting the HOWTO with a link to the original version, so the link to the forum might be given in the gcc-3.4.x ebuilds.
no real gain i think regardless of how much gentoo-wiki.com is used, we dont link to it from our documentation or ebuilds because that would imply that our developers have looked it over and marked it 'official' ... gentoo-wiki.com is a pretty nice unofficial site, but it's just that, unofficial
(In reply to comment #3) > no real gain i think Well, if there was informations about what to do after having emerged gcc-3.4, the gain would have been me avoiding wasting hours on a problem with some software (like SCIM & co), which was directly related to the fact I didn't do anything special, after emerging gcc-3.4, because the ebuild did not said anything about potential problems. I sure should have read the doc, etc. but I didn't, because most of time, there is at least some kind of warning in the ebuild. As there was no warning, I didn't think, until some time, gcc-3.4 could be the cause of the problem. (In reply to comment #3) > regardless of how much gentoo-wiki.com is used, we dont link to it from our > documentation or ebuilds because that would imply that our developers have > looked it over and marked it 'official' ... gentoo-wiki.com is a pretty nice > unofficial site, but it's just that, unofficial Like I said in my last comment, there is other ways, if you don't want to link to gentoo-wiki. The easiest being the creation of a thread in the official Gentoo forum, by a well known member (to avoid bad purposes edits), who would at least quote the gentoo-wiki HOWTO (as it's licensed under the GNU Free Documentation) and link to the original HOWTO. Then, the link to the forum thread would be put in the ebuild. Even if there is no more than one single Gentoo user who wanted to test gcc-3.4 and who avoided problems thanks to a link to some documentation in the ebuild, I think that would be an excellent gain (which cost would be near to nothing). If you do not want (well, I do not think that is the Gentoo way, but I may be mistaken), I won't insist anymore, but I'm pretty sure there will be others who will report problems (or at least have those problems), directly linked to the fact they did not do anything special after emerging gcc-3.4.x... If a user have problems, because he didn't read the documentation (well, it seems non-existent officially, which is already a problem), because there was no warning (no, the fact it's still in testing is no warning sign, whatever you would say), I think this is a pretty big problem...
linking to gentoo forums from ebuilds is just as undesirable as linking to gentoo-wiki.com the only way this will get linked in the ebuild is if someone rewrites the doc as part of the gentoo documentation project
Which, given the difference in license, can't easily be done. The wiki uses GNU's FDL (not 100% valid though if I read that license correctly - but not in a way that it is illegal) while the GDP requires the CC-BY-SA license. And since the wiki is written by many authors we can't track, we can't ask them to relicense under CC-BY-SA.
Looks like nothing is going to happen about this one. FWIW, the ebuild does mention fix_libtools_files.sh echo einfo "If you have issues with packages unable to locate libstdc++.la," einfo "then try running 'fix_libtool_files.sh' on the old gcc versions." echo
Okay, something like this is going to be needed before I can mark gcc-3.4 stable on x86 since users surely aren't going to know what they are doing.
Okay, to be specific the current request is for a brief doc that explains what needs to be done to safely use an upgraded gcc as the system compiler. It would be nice if we could make it a bit more general than just gcc-3.3x --> gcc-3.4x. Issues: * upgrading gcc not an issue unless the new compiler is set as the system compiler (the one used w/in emerge/ebuild), which is usually done via gcc-config * The main danger is having programs that link to the current and a previous libstdc++ library simultaneously. This sort of multiple linkage leads to fascinating failures in KDE, for example. * The solution is simple: "emerge -e system && emerge -e world" after running gcc-config to select the new compiler * Binary packages such as openoffice and mozilla-firefox-bin will still link to the old c++ library. Not only is this behavior expected, but it is, in fact, desired. * Something about when the old gcc's can be removed. I assume that it should be safe after the "emerge -e world", but somebody who actually knows something about this should provide some input here. * Users of ccache need to clear the cache?
(In reply to comment #9) > * Something about when the old gcc's can be removed. I assume that it should > be safe after the "emerge -e world", but somebody who actually knows > something about this should provide some input here. Should be safe, so long as they: emerge --oneshot libstdc++-v3 afterwards so binary apps don't break. It should be pulled in as a dep of gcc-3.4, but won't be if they just emerge -C =gcc-3.3.* and expect things to work. > > * Users of ccache need to clear the cache? No idea, don't think it should prove to be a problem, but I don't use ccache. Another thing we might want to say is that people might get failures when doing emerge -e system if they have a GCC-3.4 cflag specified and they still have gcc-3.3 installed. We don't filter out all of those flags as far as I'm aware, and would start to get quite cumbersome given time. Also, I would like something really short put together as soon as possible since this upgrade has been delayed long enough already. People just made it apparent to me that a doc is going to be needed for this...so, sorry for the somewhat short notice.
Here are some suggestions: I would suggest writing emerge -e system and emerge -e world into 2 following lines. Some users may be confused where (system or world) the process broke in case they run into problems. By making 2 instructions out of it, this issue will hopefully be resolved. Mentioning emerge --resume to continue operation would be a good idea, too. I also just had a weird problem with references to /etc/env.d/gcc/i686-pc-linux-gnu-3.3.5 even though i upgraded from 3.3.6, it may be a good idea to mention that gcc-config seems to be only successful if the chosen compiler actually has an asterisk in gcc-config -l (didn't check, but i guess it hasn't been in my case even though i executed gcc-config). Let's link this thread on the forums: https://forums.gentoo.org/viewtopic-t-407840.html It's currently empty and only available to developers, but we can move it to the public forums for common problems related to this upgrade. Tell people to take their time. If people rush the upgrade, a real lot of people seeking help could hit us at once. The document should mention that they don't have to do this immedeately, but do it when they have some time for the upgrade. Especially the emerge -e part may bring a lot of unnoticed bugs to light and if all people do it at the same time things could get crowded.
Well, since emerge -e world is going to probably upset people, the einfo from gcc-3.4 is probably good enough: einfo "You should make sure to rebuild all your C++ packages when" einfo "upgrading between different versions of gcc. For example," einfo "when moving to gcc-3.4 from gcc-3.3, emerge gentoolkit and run:" einfo " # revdep-rebuild --library libstdc++.so.5"
Just one more update from me. I would like to mark gcc-3.4.4-r1 stable by Friday at the latest. If we could get something together before then, it would be great, if not, all the same to me. x86 is the last to make this move, and all other archs seem to have coped well enough. The only major issue is the libstdc++ crap, which has been in einfo at the end of the merge for awhile now.
In case anyone is interested, i've updated the preliminary sticky thread: https://forums.gentoo.org/viewtopic-t-407840.html
(In reply to comment #10) > (In reply to comment #9) > > * Users of ccache need to clear the cache? > > No idea, don't think it should prove to be a problem, but I don't use ccache. Well, no - they don't need to, but it essentially gets invalidated so it will contain lots of useless stuff that won't be used any more if they don't clear it.
(In reply to comment #12) > Well, since emerge -e world is going to probably upset people, the einfo from > gcc-3.4 is probably good enough: I've seen really lots of invalid bugs because of people not being aware how to update their system after updating gcc, the often quoted bug 64615 is only one of them. I can tell you that these bug reports get quite annoying after a while and would appreciate it to see an extra announcement.
(In reply to comment #16) > I've seen really lots of invalid bugs because of people not being aware how to > update their system after updating gcc, the often quoted bug 64615 is only one > of them. I can tell you that these bug reports get quite annoying after a while > and would appreciate it to see an extra announcement. I think amne summed everything up pretty well at: https://forums.gentoo.org/viewtopic-t-407840.html If they follow those instructions, they shouldn't run into the KDE issue. Perhaps with amne's permission someone could GuideXML'ify this? Seems to cover most of the things we have discussed.
GuideXML done (with slight modifications)... http://www.gentoo.org/proj/en/base/x86/gcc-upgrade-guide.xml (when it syncs)
Very nice, looks even better now.
Thanks for your help wolf and amne.
