Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 18:37 +0100, Andreas Proschofsky wrote: It's not that easy for every package. For instance openoffice and openoffice-bin need to got to the same location, cause OOo does a user install and this will break when changing between them (and all the settings / paths and so on). So either we would have both in /opt which then means that the source based OOo is ignored too, or we have them in /usr/lib which results in the ooo-bin annoyance. I would say the second one is less harmful. Btw, there is a long running bug about the revdep-rebuild, which also has a solution for this: https://bugs.gentoo.org/show_bug.cgi?id=32276 While we are talking about this, I would like to point out the following message that I sent here on November 3rd: http://article.gmane.org/gmane.linux.gentoo.devel/32556/ To summarize, in order for revdep-rebuild to ignore binary packages, it needs help from the package maintainers. This is done, by the package installing a file into /etc/revdep-rebuild/ that tells revdep-rebuild what directories to ignore. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Thu, 2005-12-01 at 01:30 +0100, Marien Zwart wrote: On Wed, 30 Nov 2005 18:50:02 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Jakub Moc [EMAIL PROTECTED] said: 1.12.2005, 0:29:48, Chris Gianelloni wrote: revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. Yea, I updated my statement on the bug to reflect this. C++ stuff should be the only thing affected, so this _should_ be enough. Its also already something that's been in the ebuild for a while now. Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. How right you are; that just happend to me two days ago after removing gcc-3.3.6 before emerge -e system on x86. Luckily it was a fresh install ... matthias -- Marien. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Fri, 2005-12-02 at 03:03 +0100, Matthias Langer wrote: On Thu, 2005-12-01 at 01:30 +0100, Marien Zwart wrote: On Wed, 30 Nov 2005 18:50:02 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Jakub Moc [EMAIL PROTECTED] said: 1.12.2005, 0:29:48, Chris Gianelloni wrote: revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. Yea, I updated my statement on the bug to reflect this. C++ stuff should be the only thing affected, so this _should_ be enough. Its also already something that's been in the ebuild for a while now. Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. How right you are; that just happend to me two days ago after removing gcc-3.3.6 before emerge -e system on x86. Luckily it was a fresh install ... But besides of this fact, which was my very own fault, i'm very happy with gcc-3.4. I thought, that maybe some c++ packages would fail to compile, as I'm a c++ devel myself and know that there are differneces in the c++ code that gcc-3.3.x and gcc-3.4.x are accepting. However, I'm running gcc-3.4 now on 2 of 3 gentoo boxes i'm mentaining and are very pleased with the results. matthias matthias -- Marien. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 23:41 -0500, Andrew Muraco wrote: Out of curiosity, if this goes into effect before 2006.0 is released, then ALL the stages for x86 and the livecd would be built with gcc34? If so then I think this may benefit alot of users, especially ones that do a stage1/2 just so they can shove gcc34 into there system at an early stage. Also, if gcc34 gets moved to x86, would gcc40 be ~x86? This I see as a bigger problem for those of us that are already running gcc34. But I'm sure many ~x86 users would welcome that, after all what fun is ~x86 without some breakage every now and then ;-) 2006.0 is still a ways off, but yes, all of the stages would be built with gcc 3.4 exclusively. Of course, this would happen whether we made the change globally (for x86) or if we only did it via profile. The problem with doing it via profile is we *already have* people on 2005.0 and 2005.1 profiles running gcc 3.4, so it means causing a much more disruptive upgrade for all ~x86 users, or anyone who has merged gcc 3.4 explicitly already. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 23:41 -0500, Andrew Muraco wrote: Out of curiosity, if this goes into effect before 2006.0 is released, then ALL the stages for x86 and the livecd would be built with gcc34? If so then I think this may benefit alot of users, especially ones that do a stage1/2 just so they can shove gcc34 into there system at an early stage. Also, if gcc34 gets moved to x86, would gcc40 be ~x86? This I see as a bigger problem for those of us that are already running gcc34. But I'm sure many ~x86 users would welcome that, after all what fun is ~x86 without some breakage every now and then ;-) 2006.0 is still a ways off, but yes, all of the stages would be built with gcc 3.4 exclusively. Of course, this would happen whether we made the change globally (for x86) or if we only did it via profile. The problem with doing it via profile is we *already have* people on 2005.0 and 2005.1 profiles running gcc 3.4, so it means causing a much more disruptive upgrade for all ~x86 users, or anyone who has merged gcc 3.4 explicitly already. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux Again, would anyone know what will happen to ~x86 gcc?, Will it become gcc40 or just use the stable x86 gcc for everyone? (except those who are already playing with gcc40 at their own risk) Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
[EMAIL PROTECTED] writes: Again, would anyone know what will happen to ~x86 gcc?, Will it become gcc40 or just use the stable x86 gcc for everyone? (except those who are already playing with gcc40 at their own risk) Even if ~x86 does change to gcc40 then gcc is slotted so we can continue to use gcc3.4.4. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Mark Loeser [EMAIL PROTECTED] said: Only thing I see as lacking is we might want to get a doc together on how to properly upgrade your toolchain so we don't get an influx of bugs from users that have a system half compiled with 3.3 and the other half with 3.4 so they get linking errors. Seems people read this to mean that I was going to write a doc, which I have no intentions on doing. I believe adding It is recommended that you `emerge -e system emerge -e world` after merging gcc-3.4 to the einfo at the end of the gcc-3.4.4 install should be good enough. I'm not sure how other archs handled the migration, but I haven't been able to find any docs online. So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpq7g9SRNKO0.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Mark Loeser wrote: So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. gentoo-announce at least. I wish emerge --news was already here. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, Nov 30, 2005 at 01:56:40PM -0500, Mark Loeser wrote: Seems people read this to mean that I was going to write a doc, which I have no intentions on doing. I don't think a whole doc is necessary, but instructions for a safe upgrade would be fine. A think a one-liner like emerge -u gcc emerge -e system emerge -e world emerge -P gcc emerge whateverneedstobedoneafterwards should suffice as documentation. I believe adding It is recommended that you `emerge -e system emerge -e world` after merging gcc-3.4 to the einfo at the end of the gcc-3.4.4 install should be good enough. Maybe people look closer if they upgrade gcc, but einfo still gets overlooked easily. So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. Assuming a clear upgrade path is provided i think it would be fine. We'll make some sticky thread on the forum mentioning that instructions, i bet it couldn't hurt to put them on the gentoo mainpage, as topic in #gentoo etc. I'm also pretty sure next GWN is likely to report about the update. Just because we haven't got emerge --news it doesn't mean we haven't got lots of ways to reach our users. Every user that gets to read them in time is a potential bug report less. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Wernfried Haas wrote: On Wed, Nov 30, 2005 at 01:56:40PM -0500, Mark Loeser wrote: Seems people read this to mean that I was going to write a doc, which I have no intentions on doing. I don't think a whole doc is necessary, but instructions for a safe upgrade would be fine. A think a one-liner like emerge -u gcc emerge -e system emerge -e world emerge -P gcc emerge whateverneedstobedoneafterwards should suffice as documentation. I believe adding It is recommended that you `emerge -e system emerge -e world` after merging gcc-3.4 to the einfo at the end of the gcc-3.4.4 install should be good enough. Maybe people look closer if they upgrade gcc, but einfo still gets overlooked easily. So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. Assuming a clear upgrade path is provided i think it would be fine. We'll make some sticky thread on the forum mentioning that instructions, i bet it couldn't hurt to put them on the gentoo mainpage, as topic in #gentoo etc. I'm also pretty sure next GWN is likely to report about the update. Just because we haven't got emerge --news it doesn't mean we haven't got lots of ways to reach our users. Every user that gets to read them in time is a potential bug report less. cheers, Wernfried Personally, I would set a date next week, so that way GWN and other places can be prepare for this, a definate date for users to know that it IS going to happen, and I personally think that a sticky on the forum (i would even be willing to write a little something, but i'm no expert) is a minimum. A full out doc with all the FAQ and important notes about what needs to be recompiled (in my opinion) would be a much more through upgrade path, ofcourse still include the einfo quick instructions. But I think the masses of users will not be happy when they realize that emerge -e world emerge -e world means that they will be compiling for the next day (or 2 or 3), so a way to block the upgrade from messing up people that wish to keep 3.3.x as default would be a good idea. just my $.02 Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Andrew Muraco [EMAIL PROTECTED] said: is a minimum. A full out doc with all the FAQ and important notes about what needs to be recompiled (in my opinion) would be a much more through upgrade path, ofcourse still include the einfo quick instructions. But I think the masses of users will not be happy when they realize that emerge -e world emerge -e world means that they will be compiling for the next day (or 2 or 3), so a way to block the upgrade from messing up people that wish to keep 3.3.x as default would be a good idea. gcc-3.4.* will not be selected as your system compiler after merging it. The old gcc profile is still valid, therefore it is kept. Users have to consciously go and change their profile to change their gcc, so nothing is going to just magically break. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpUWJPetVoI1.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Georgi Georgiev wrote: maillog: 30/11/2005-15:16:35(-0500): Andrew Muraco types Mark Loeser wrote: Andrew Muraco [EMAIL PROTECTED] said: is a minimum. A full out doc with all the FAQ and important notes about what needs to be recompiled (in my opinion) would be a much more through upgrade path, ofcourse still include the einfo quick instructions. But I think the masses of users will not be happy when they realize that emerge -e world emerge -e world means that they will be compiling for the next day (or 2 or 3), so a way to block the upgrade from messing up people that wish to keep 3.3.x as default would be a good idea. gcc-3.4.* will not be selected as your system compiler after merging it. The old gcc profile is still valid, therefore it is kept. Users have to consciously go and change their profile to change their gcc, so nothing is going to just magically break. That makes me feel a bit more comfortable. I still think that something more then an einfo warning should be provided, as its easy to overlook those. So make gcc-config produce warnings when changing the compiler. Switching to gcc-MAJOR.MINOR may break your system. Upgrade instructions can be found at http://thedoc; Trigger the message only when switching minor versions. I like that idea alot actually. Perhaps also include in that warning message that switching back is OKAY aslong as nothing has been compiled with the new minor version. :-P I vote for this choice. Greetings, Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Georgi Georgiev [EMAIL PROTECTED] said: So make gcc-config produce warnings when changing the compiler. Switching to gcc-MAJOR.MINOR may break your system. Upgrade instructions can be found at http://thedoc; Trigger the message only when switching minor versions. That's going to be really really annoying for someone like me that flips between gcc versions all the time to test things. How to inform users of updates is not really the scope here though (go argue this on the news GLEP). Making sure the information for how to properly upgrade is available is what we are looking at. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpzZTFpcaErN.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 2005-11-30 at 13:56 -0500, Mark Loeser wrote: Mark Loeser [EMAIL PROTECTED] said: Only thing I see as lacking is we might want to get a doc together on how to properly upgrade your toolchain so we don't get an influx of bugs from users that have a system half compiled with 3.3 and the other half with 3.4 so they get linking errors. Seems people read this to mean that I was going to write a doc, which I have no intentions on doing. I believe adding It is recommended that you `emerge -e system emerge -e world` after merging gcc-3.4 to the einfo at the end of the gcc-3.4.4 install should be good enough. I'm not sure how other archs handled the migration, but I haven't been able to find any docs online. So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. einfo $stuff and mark it stable later today wins my vote. -- solar [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
051130 Andrew Muraco wrote: I think the masses of users will not be happy when they realize that 'emerge -e world emerge -e world' ... Should that be 'emerge -e system emerge -e world' ? ... means that they will be compiling for the next day or 2 or 3 , /spectate As one of the masses, I am certainly disturbed at that implication. I don't remember any such need when I upgraded 2.9.5 - 3.x (now 3.3.6). This is the kind of issue on which I trust the devs to do sensible things, but do we really need to rebuild our whole systems from the ground up ? Ordinarily, I upgrade packages individually when it seems appropriate never do 'emerge world' with or without '-e' or other flags; I do 'esync' every weekend look at what is marked as having changed. I would very much appreciate a doc somewhere which explains the advantages of moving to 3.4 why a wholesale ground-up rebuild is necessary, if indeed it is. As always, my thanks to those who do the volunteer work. -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 30 Nov 2005 17:34:56 -0500 Philip Webb [EMAIL PROTECTED] wrote: | As one of the masses, I am certainly disturbed at that implication. | I don't remember any such need when I upgraded 2.9.5 - 3.x (now | 3.3.6). The 2.x - 3.x upgrade was far worse. Maybe you're just repressing the memory of it... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Philip Webb wrote: [Wed Nov 30 2005, 04:34:56PM CST] As one of the masses, I am certainly disturbed at that implication. I don't remember any such need when I upgraded 2.9.5 - 3.x (now 3.3.6). http://www.gentoo.org/doc/en/new-upgrade-to-gentoo-1.4.xml -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgptsXmrzu1x2.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Philip Webb [EMAIL PROTECTED] said: I would very much appreciate a doc somewhere which explains the advantages of moving to 3.4 why a wholesale ground-up rebuild is necessary, if indeed it is. As always, my thanks to those who do the volunteer work. C++ compat was broken between 3.3 and 3.4, so C++ libs compiled against 3.3 and 3.4 aren't going to play nice with each other. KDE is the common example of breakage here. If I'm wrong, then someone will hopefully correct me here, but this is the only way to keep everything sane as far as I know. As for a doc, look at: https://bugs.gentoo.org/show_bug.cgi?id=102876 I'm hoping we can get something thrown together relatively quickly so I can mark it stable. Nothing is going to be required immediately from the user though, since their compiler won't be changed to 3.4 until they do so. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpn8ucW9Srof.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 2005-11-30 at 17:34 -0500, Philip Webb wrote: As one of the masses, I am certainly disturbed at that implication. I don't remember any such need when I upgraded 2.9.5 - 3.x (now 3.3.6). This is the kind of issue on which I trust the devs to do sensible things, but do we really need to rebuild our whole systems from the ground up ? Lots of things broke way back then, too. Also, there wasn't even slotted gcc ebuilds back then, so it really is hard to compare. There were a lot of things done in the past that were really broken that we have since learned from... Ordinarily, I upgrade packages individually when it seems appropriate never do 'emerge world' with or without '-e' or other flags; I do 'esync' every weekend look at what is marked as having changed. Technically, you don't need to rebuild world. You only need to rebuild stuff that uses C++ and links to libstdc++. I would very much appreciate a doc somewhere which explains the advantages of moving to 3.4 why a wholesale ground-up rebuild is necessary, if indeed it is. As always, my thanks to those who do the volunteer work. Well, the advantages are simple. Upstream no longer supports 3.3 anymore. They barely support 3.4, but having some support from upstream is better than none. This means 3.3 will be relegated to a legacy version and likely won't be updated except for security bugs. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Jakub Moc [EMAIL PROTECTED] said: 1.12.2005, 0:29:48, Chris Gianelloni wrote: Technically, you don't need to rebuild world. You only need to rebuild stuff that uses C++ and links to libstdc++. revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. Yea, I updated my statement on the bug to reflect this. C++ stuff should be the only thing affected, so this _should_ be enough. Its also already something that's been in the ebuild for a while now. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpMsWalxXe7V.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 30 Nov 2005 18:50:02 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Jakub Moc [EMAIL PROTECTED] said: 1.12.2005, 0:29:48, Chris Gianelloni wrote: revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. Yea, I updated my statement on the bug to reflect this. C++ stuff should be the only thing affected, so this _should_ be enough. Its also already something that's been in the ebuild for a while now. Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. -- Marien. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Thu, 1 Dec 2005 01:53:25 +0100 Jakub Moc [EMAIL PROTECTED] wrote: 1.12.2005, 1:30:41, Marien Zwart wrote: Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. Which returns us to the question why don't we build python with nocxx so that we could avoid this major PITA. Actually I'm looking into that. According to the information I have found on the python-dev list and in python's documentation the libstdc++ link is not needed, but a dev asked a python herd member for it, and therefore the link was added. Haven't caught that dev yet, so at the moment I don't know why that link is there. If someone on this list knows the reason it was added, please enlighten me. -- Marien. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
051130 Chris Gianelloni wrote: On Wed, 2005-11-30 at 17:34 -0500, Philip Webb wrote: As one of the masses, I am certainly disturbed at that implication. I don't remember any such need when I upgraded 2.9.5 - 3.x (now 3.3.6). This is the kind of issue on which I trust the devs to do sensible things, but do we really need to rebuild our whole systems from the ground up ? Ordinarily, I upgrade packages individually when it seems appropriate never do 'emerge world' with or without '-e' or other flags; I do 'esync' every weekend look at what is marked as having changed. Technically, you don't need to rebuild world. You only need to rebuild stuff that uses C++ and links to libstdc++. That's what I wanted to know. From this other responses, it looks as if it would be a bad idea eg to upgrade to KDE 3.5 just before adopting GCC 3.4 (smile), but that 'revdep-rebuild' will reveal the (lengthy) list of needed remerges. I would urge whoever is documenting this to avoid a blanket recommendation to 'emerge -e system emerge -e world' or be prepared for a lot of negative reaction from the masses. spectate -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 2005-11-30 at 16:19 -0500, Mark Loeser wrote: Georgi Georgiev [EMAIL PROTECTED] said: So make gcc-config produce warnings when changing the compiler. Switching to gcc-MAJOR.MINOR may break your system. Upgrade instructions can be found at http://thedoc; Trigger the message only when switching minor versions. That's going to be really really annoying for someone like me that flips between gcc versions all the time to test things. New flag? # gcc-config -q foo -q == quiet just a thought -- Lares Moreau [EMAIL PROTECTED] | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 03:40, Mark Loeser wrote: Mike Frysinger [EMAIL PROTECTED] said: that means when people upgrade to gcc-3.4, gcc-3.3 will remain on their system until they remove it so if user fails to rebuild all their packages before unmerging gcc-3.3 they will be screwed, but OH WELL Yea. Even after they remove it though, libstdc++-v3 should be pulled in after that. Only issue I really see is people that have libraries compiled with 3.3 and 3.4 and don't know why stuff is broken. I don't know how large of a problem that will be though. It will be huge, see https://bugs.gentoo.org/show_bug.cgi?id=64615 https://bugs.gentoo.org/show_bug.cgi?id=61146 Every user _must_ be instructed to run 'revdep-rebuild --soname libstdc++.so.5', if a system contains things linking to libstdc++.so.5 and things linking to libstdc++.so.6 I consider it horribly broken. Thus having libstdc++-v3 installed apparently solves a problem but in fact does not solve anything, the only solution is to recompile everything c++ related on the system. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 03:40, Mark Loeser wrote: Mike Frysinger [EMAIL PROTECTED] said: that means when people upgrade to gcc-3.4, gcc-3.3 will remain on their system until they remove it so if user fails to rebuild all their packages before unmerging gcc-3.3 they will be screwed, but OH WELL Yea. Even after they remove it though, libstdc++-v3 should be pulled in after that. Only issue I really see is people that have libraries compiled with 3.3 and 3.4 and don't know why stuff is broken. I don't know how large of a problem that will be though. From my own experience of updating quite some while ago, I remember that the libraries are sufficiently compatible such that not so many bugs occur. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpgPDQYl0K6g.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 09:51, Gregorio Guidi wrote: Every user _must_ be instructed to run 'revdep-rebuild --soname libstdc++.so.5', if a system contains things linking to libstdc++.so.5 and things linking to libstdc++.so.6 I consider it horribly broken. A system is only horribly broken if it contains binaries or libraries that link to both libstdc++.so.5 *and* libstdc++.so.6. This creates instabilities. The situation you describe is only that of a system in transition. Thus having libstdc++-v3 installed apparently solves a problem but in fact does not solve anything, the only solution is to recompile everything c++ related on the system. It is also needed for third party apps that were linked against libstdc++.so.5. As long as those applications do not depend on other libraries that are linked against a newer c++ lib things are totally ok. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpF7GpJX0UML.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Paul de Vrieze [EMAIL PROTECTED] writes: It is also needed for third party apps that were linked against libstdc++.so.5. As long as those applications do not depend on other libraries that are linked against a newer c++ lib things are totally ok. But unfortunately is does happen. For example on my system (~x86 built with gcc 3.4.4) opera is linked against libstdc++.so.5 and libqt-mt.so.3 which in turn is linked against libstdc++.so.6 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 10:53, Graham Murray wrote: Paul de Vrieze [EMAIL PROTECTED] writes: It is also needed for third party apps that were linked against libstdc++.so.5. As long as those applications do not depend on other libraries that are linked against a newer c++ lib things are totally ok. But unfortunately is does happen. For example on my system (~x86 built with gcc 3.4.4) opera is linked against libstdc++.so.5 and libqt-mt.so.3 which in turn is linked against libstdc++.so.6 Opera is indeed an example of an application where it doesn't work. Mozilla, the jdk's and many games are however good examples. The general rule is that using libraries written in c++ doesn't work for transitioning. This is partly caused by the fact that the linker makes all symbols global, and as such doesn't look at (or record) the soname of the library where the symbol is supposed to come from. Please be aware though that doing so would still not fix c++ issues as extending objects with one symbol table (and library of origin) with objects (children) with another symbol table (and library of origin) is bound to break. If for example a library function returns a c++ string object. Which methods should then be used on this object? Paul ps. The sandbox we use in portage actually also relies on this behaviour of the linker, as we replace glibc symbols by our own versions of them that check permissions. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpssmaZzoOLH.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Mon, Nov 28, 2005 at 09:22:33AM -0500, Mark Loeser wrote: This is basically a heads-up email to everyone to say that we are probably going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the archs that have already done the move from having 3.3 stable to 3.4 could give us a heads up on what to expect, that would be great. Only thing I see as lacking is we might want to get a doc together on how to properly upgrade your toolchain so we don't get an influx of bugs from users that have a system half compiled with 3.3 and the other half with 3.4 so they get linking errors. We will also need to instruct users to recompile their kernel with gcc-3.4 otherwise the external modules (which will be recompiled with gcc-3.4 during `emerge -e world`) will fail to load because of vermagic mismatch. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpkQs96Fa7ch.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 12:18, Henrik Brix Andersen wrote: gcc-3.4 during `emerge -e world`) will fail to load because of Why should one do that? It's not needed. But of course recompiling the kernel and external modules at some point makes sense. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpWPQFAN8xtW.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Henrik Brix Andersen [EMAIL PROTECTED] said: We will also need to instruct users to recompile their kernel with gcc-3.4 otherwise the external modules (which will be recompiled with gcc-3.4 during `emerge -e world`) will fail to load because of vermagic mismatch. This assumes that they do an `emerge -e world'. We aren't going to be able to protect users from all of the stupid mistakes they can make, but the upgrade path is sane and very doable. Perhaps the docs team could come up with a generic toolchain guide that will possibly help stop any of the stupid mistakes users could make. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpgktGju3Vxt.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Speaking as a user who upgraded from 3.3.x to 3.4.x a loong lng time ago and also as a forum mod who sees questins about this on a daily basis: Users are more or less aware that they will have to rebuild the entire world including the kernel when they upgrade gcc. If they aren't already aware of it they soon learn that it is necessary and they aren't averse to it. This is a from source distro afterall, so TELLING them in an upgrade guide that they *HAVE* to do this wouldn't be such a bad thing. It solves 99% of all the problems reported in a gcc upgrade for people who *didn't* do an emerge -e world. Doing it from the outset will save the forums and bugs a lot of stress and heartache that could have been easily avoided. Just my 2 $DENOMINATION's -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
As a user who has done this on a number of systems - its no sweat. Also, check some of the older guides for upgrading from gcc-2.95 to 3, and 3.0 to 3.1 - should still be around somewhere. Its been done before, more than once - ask some of the older devs whove been around since the early days(!). Traps this time were uninstalling 3.3.6 without installing the sys-libs/libstdc++-v3 first. Ive put off removing 3.3.6 from the other systems until I get the nerve up again. So as well as instructions to do the task, some rescue for common mistakes like this would be nice. BillK On Tue, 2005-11-29 at 08:50 -0500, Curtis Napier wrote: Speaking as a user who upgraded from 3.3.x to 3.4.x a loong lng time ago and also as a forum mod who sees questins about this on a daily basis: Users are more or less aware that they will have to rebuild the entire world including the kernel when they upgrade gcc. If they aren't already aware of it they soon learn that it is necessary and they aren't averse to it. This is a from source distro afterall, so TELLING them in an upgrade guide that they *HAVE* to do this wouldn't be such a bad thing. It solves 99% of all the problems reported in a gcc upgrade for people who *didn't* do an emerge -e world. Doing it from the outset will save the forums and bugs a lot of stress and heartache that could have been easily avoided. Just my 2 $DENOMINATION's -- William Kenworthy [EMAIL PROTECTED] Home! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 09:51 +0100, Gregorio Guidi wrote: On Tuesday 29 November 2005 03:40, Mark Loeser wrote: Mike Frysinger [EMAIL PROTECTED] said: that means when people upgrade to gcc-3.4, gcc-3.3 will remain on their system until they remove it so if user fails to rebuild all their packages before unmerging gcc-3.3 they will be screwed, but OH WELL Yea. Even after they remove it though, libstdc++-v3 should be pulled in after that. Only issue I really see is people that have libraries compiled with 3.3 and 3.4 and don't know why stuff is broken. I don't know how large of a problem that will be though. It will be huge, see https://bugs.gentoo.org/show_bug.cgi?id=64615 https://bugs.gentoo.org/show_bug.cgi?id=61146 Every user _must_ be instructed to run 'revdep-rebuild --soname libstdc++.so.5', if a system contains things linking to libstdc++.so.5 and things linking to libstdc++.so.6 I consider it horribly broken. *sigh* ...and when it tries to recompile openoffice-bin? doom3? A system linked against both libraries is definitely *not* broken, as there are plenty of cases where this is necessary. Thus having libstdc++-v3 installed apparently solves a problem but in fact does not solve anything, the only solution is to recompile everything c++ related on the system. Except the binary apps that you don't have the source to be able to recompile. So now we're right back where we were, aren't we? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Monday 28 November 2005 14:22, Mark Loeser wrote:
This is basically a heads-up email to everyone to say that we are probably
going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the
archs that have already done the move from having 3.3 stable to 3.4 could
give us a heads up on what to expect, that would be great. Only thing I
see as lacking is we might want to get a doc together on how to properly
upgrade your toolchain so we don't get an influx of bugs from users that
have a system half compiled with 3.3 and the other half with 3.4 so they
get linking errors.
Shouldn't this be a profile thing? i.e. 200{4,5}.X stays at 3.3.X, 2006.X- go
to 3.4.X
--
Mike Williams
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, Nov 29, 2005 at 09:50:34AM -0500, Chris Gianelloni wrote: On Tue, 2005-11-29 at 09:51 +0100, Gregorio Guidi wrote: Every user _must_ be instructed to run 'revdep-rebuild --soname libstdc++.so.5', if a system contains things linking to libstdc++.so.5 and things linking to libstdc++.so.6 I consider it horribly broken. ...and when it tries to recompile openoffice-bin? doom3? revdep-rebuild should ignore those packages -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 15:01 +, Mike Williams wrote:
On Monday 28 November 2005 14:22, Mark Loeser wrote:
This is basically a heads-up email to everyone to say that we are probably
going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the
archs that have already done the move from having 3.3 stable to 3.4 could
give us a heads up on what to expect, that would be great. Only thing I
see as lacking is we might want to get a doc together on how to properly
upgrade your toolchain so we don't get an influx of bugs from users that
have a system half compiled with 3.3 and the other half with 3.4 so they
get linking errors.
Shouldn't this be a profile thing? i.e. 200{4,5}.X stays at 3.3.X, 2006.X-
go
to 3.4.X
Nope.
While it would be possible to limit it to a specific profile, it really
makes it a pain in the ass, especially for two versions that are almost
compatible, as opposed to the profiles that we have done in the past
where we were going from things like gcc2 to gcc3, that were not very
compatible, at all.
--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 15:03 +, Mike Frysinger wrote: On Tue, Nov 29, 2005 at 09:50:34AM -0500, Chris Gianelloni wrote: On Tue, 2005-11-29 at 09:51 +0100, Gregorio Guidi wrote: Every user _must_ be instructed to run 'revdep-rebuild --soname libstdc++.so.5', if a system contains things linking to libstdc++.so.5 and things linking to libstdc++.so.6 I consider it horribly broken. ...and when it tries to recompile openoffice-bin? doom3? revdep-rebuild should ignore those packages Just curious, but how? How does it know that doom3 isn't compiled from source and should be ignored? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, Nov 29, 2005 at 08:21:51AM -0500, Mark Loeser wrote: This assumes that they do an `emerge -e world'. Well, the same problem will arise should they upgrade their gcc and install a new external kernel module (with or without `emerge -e world`). Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpsDnLzB7Lu1.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 10:42 -0500, Chris Gianelloni wrote: On Tue, 2005-11-29 at 15:03 +, Mike Frysinger wrote: On Tue, Nov 29, 2005 at 09:50:34AM -0500, Chris Gianelloni wrote: On Tue, 2005-11-29 at 09:51 +0100, Gregorio Guidi wrote: Every user _must_ be instructed to run 'revdep-rebuild --soname libstdc++.so.5', if a system contains things linking to libstdc++.so.5 and things linking to libstdc++.so.6 I consider it horribly broken. ...and when it tries to recompile openoffice-bin? doom3? revdep-rebuild should ignore those packages Just curious, but how? How does it know that doom3 isn't compiled from source and should be ignored? broken /usr/lib32/openoffice/program/gconfbe1.uno.so (requires libORBit-2.so.0 libgconf-2.so.4) broken /usr/lib32/openoffice/program/gnome-set-default-application (requires libORBit-2.so.0 libORBitCosNaming-2.so.0 libbonobo-2.so.0 libbonobo-activation.so.4 libgconf-2.so.4 libgnomevfs-2.so.0) broken /usr/lib32/openoffice/program/libofficebean.so.1.1 (requires libjawt.so) broken /usr/lib32/openoffice/program/libvclplug_kde680li.so.1.1 (requires libkdecore.so.4 libkdeui.so.4 libqt-mt.so.3) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/_bsddb.so (requires libdb-3.1.so) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/_tkinter.so (requires libBLT24.so libtcl8.3.so libtk8.3.so) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/bz2.so (requires libbz2.so.0) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/dbm.so (requires libgdbm.so.2) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/gdbm.so (requires libgdbm.so.2) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/mpz.so (requires libgmp.so.3) broken /usr/lib32/openoffice/program/ucpgvfs1.uno.so (requires libgnomevfs-2.so.0) These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-office/openoffice-bin-2.0.0 It most definitely does not recognize binary packages of any kind. Just to let you know, every successful revdep-rebuild followed by another also wants openoffice-bin again. Interestingly enough, it did *not* list any of the games I have installed on that machine that are in /opt. Is /opt ignored? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, Nov 29, 2005 at 10:52:11AM -0500, Chris Gianelloni wrote: broken /usr/lib32/openoffice/program/gconfbe1.uno.so (requires libORBit-2.so.0 libgconf-2.so.4) binary packages should never be in /usr/ Is /opt ignored? yes, because our policy specifically says binary packages in /opt -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 08:50 -0500, Curtis Napier wrote: Doing it from the outset will save the forums and bugs a lot of stress and heartache that could have been easily avoided. Don't forget the #gentoo channel. I meant to comment on this about the stage 1/2 thing but never did. I'm not picking sides but if the forum mods and the channel ops were both notified explicitly of changes that *are* coming then we could help head off a bunch of bugs and user aggravation. I'm pretty active in most places Gentoo but the first I heard about the stage 1/2 removal was GWN. If you could drop an email to the forum-mods address (??) and [EMAIL PROTECTED] a few days or so before something gets to the users that would be great. Just my 2 $DENOMINATION's My 2/100 $DENOMINATION's :) -- Tres Melton IRC Gentoo: RiverRat signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 16:04 +, Mike Frysinger wrote: On Tue, Nov 29, 2005 at 10:52:11AM -0500, Chris Gianelloni wrote: broken /usr/lib32/openoffice/program/gconfbe1.uno.so (requires libORBit-2.so.0 libgconf-2.so.4) binary packages should never be in /usr/ Is /opt ignored? yes, because our policy specifically says binary packages in /opt It's not that easy for every package. For instance openoffice and openoffice-bin need to got to the same location, cause OOo does a user install and this will break when changing between them (and all the settings / paths and so on). So either we would have both in /opt which then means that the source based OOo is ignored too, or we have them in /usr/lib which results in the ooo-bin annoyance. I would say the second one is less harmful. Btw, there is a long running bug about the revdep-rebuild, which also has a solution for this: https://bugs.gentoo.org/show_bug.cgi?id=32276 bye Andreas -- Andreas Proschofsky Gentoo Developer / OpenOffice.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 18:37 +0100, Andreas Proschofsky wrote: On Tue, 2005-11-29 at 16:04 +, Mike Frysinger wrote: On Tue, Nov 29, 2005 at 10:52:11AM -0500, Chris Gianelloni wrote: broken /usr/lib32/openoffice/program/gconfbe1.uno.so (requires libORBit-2.so.0 libgconf-2.so.4) binary packages should never be in /usr/ Is /opt ignored? yes, because our policy specifically says binary packages in /opt It's not that easy for every package. For instance openoffice and openoffice-bin need to got to the same location, cause OOo does a user install and this will break when changing between them (and all the settings / paths and so on). So either we would have both in /opt which then means that the source based OOo is ignored too, or we have them in /usr/lib which results in the ooo-bin annoyance. I would say the second one is less harmful. Btw, there is a long running bug about the revdep-rebuild, which also has a solution for this: https://bugs.gentoo.org/show_bug.cgi?id=32276 Great! So it is being fixed. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Chris Gianelloni wrote:
On Tue, 2005-11-29 at 15:01 +, Mike Williams wrote:
On Monday 28 November 2005 14:22, Mark Loeser wrote:
This is basically a heads-up email to everyone to say that we are probably
going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the
archs that have already done the move from having 3.3 stable to 3.4 could
give us a heads up on what to expect, that would be great. Only thing I
see as lacking is we might want to get a doc together on how to properly
upgrade your toolchain so we don't get an influx of bugs from users that
have a system half compiled with 3.3 and the other half with 3.4 so they
get linking errors.
Shouldn't this be a profile thing? i.e. 200{4,5}.X stays at 3.3.X, 2006.X- go
to 3.4.X
Nope.
While it would be possible to limit it to a specific profile, it really
makes it a pain in the ass, especially for two versions that are almost
compatible, as opposed to the profiles that we have done in the past
where we were going from things like gcc2 to gcc3, that were not very
compatible, at all.
Out of curiosity, if this goes into effect before 2006.0 is released,
then ALL the stages for x86 and the livecd would be built with gcc34? If
so then I think this may benefit alot of users, especially ones that do
a stage1/2 just so they can shove gcc34 into there system at an early
stage. Also, if gcc34 gets moved to x86, would gcc40 be ~x86? This I see
as a bigger problem for those of us that are already running gcc34. But
I'm sure many ~x86 users would welcome that, after all what fun is ~x86
without some breakage every now and then ;-)
Greetings,
Tuxp3
Andrew Muraco
www.leetworks.com
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Mon, Nov 28, 2005 at 09:22:33AM -0500, Mark Loeser wrote: Only thing I see as lacking is we might want to get a doc together on how to properly upgrade your toolchain so we don't get an influx of bugs from users that have a system half compiled with 3.3 and the other half with 3.4 so they get linking errors. there is a bug open about this issue ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does this mean that we can get rid of the libstd++ dependency of gcc, and move it to the binary packages that depends on gcc 3.3 . I know this has been discussed before, but once it's stable I see no reason to keep the dependency in the gcc ebuild, when it could be in the binary packages. Bjarke Mark Loeser skrev: This is basically a heads-up email to everyone to say that we are probably going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the archs that have already done the move from having 3.3 stable to 3.4 could give us a heads up on what to expect, that would be great. Only thing I see as lacking is we might want to get a doc together on how to properly upgrade your toolchain so we don't get an influx of bugs from users that have a system half compiled with 3.3 and the other half with 3.4 so they get linking errors. Thanks, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDi0h3O+Ewtpi9rLERAibAAKCedui46gqRaBmwMpkufdQdw88ikQCfcgQu UybgL9DJQXbD93CxuiHztEQ= =+tUe -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Mon, Nov 28, 2005 at 05:24:52PM -0500, Daniel Gryniewicz wrote: On Mon, 2005-11-28 at 19:12 +0100, Bjarke Istrup Pedersen wrote: Does this mean that we can get rid of the libstd++ dependency of gcc, and move it to the binary packages that depends on gcc 3.3 . I know this has been discussed before, but once it's stable I see no reason to keep the dependency in the gcc ebuild, when it could be in the binary packages. Well, right after the upgrade, there will still be tons of non-binary programs built against the old libstdc++, so no. Unless you want to force everyone to emerge -e world after the upgrade (which will make you very unpopular). not really an issue ... gcc is SLOTed for everyone to gccmajor.gccminor that means when people upgrade to gcc-3.4, gcc-3.3 will remain on their system until they remove it so if user fails to rebuild all their packages before unmerging gcc-3.3 they will be screwed, but OH WELL -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Mike Frysinger [EMAIL PROTECTED] said: that means when people upgrade to gcc-3.4, gcc-3.3 will remain on their system until they remove it so if user fails to rebuild all their packages before unmerging gcc-3.3 they will be screwed, but OH WELL Yea. Even after they remove it though, libstdc++-v3 should be pulled in after that. Only issue I really see is people that have libraries compiled with 3.3 and 3.4 and don't know why stuff is broken. I don't know how large of a problem that will be though. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpCpH4fDgQDq.pgp Description: PGP signature
