[gentoo-user] Re: GCC upgrade can't run fix_libtool_files
On 16/06/14 20:02, Daniel Frey wrote: On 06/16/2014 09:56 AM, Nikos Chantziaras wrote: Does someone know what causes the error? I got this when upgrading from GCC 4.8.2 to 4.8.3: Installing (1 of 1) sys-devel/gcc-4.8.3 * gcc-config: Could not locate 'x86_64-pc-linux-gnu-4.8.2' in '/etc/env.d/gcc/' ! * Running 'fix_libtool_files.sh 4.8.2' * Scanning libtool files for hardcoded gcc library paths... * gcc-config: Active gcc profile is invalid! gcc-config: error: could not run/locate 'gcc' :0: assertion failed: (gcc -dumpversion) | getline NEWVER) It looks like you've upgraded gcc and removed the version that was currently active. What's the output of `gcc-config -l`? It should look something like this: $ sudo gcc-config -l [1] x86_64-pc-linux-gnu-4.7.3 * The asterisk means it's active. If you see a list and none are active, you need to set one. I was only interested in the fix_libtool_files.sh error. The gcc-config error is probably due to portage removing 4.8.2 when updating to 4.8.3, since it's a minor version update.
[gentoo-user] Re: GCC upgrade from 4.5.3 to 4.5.4 automatically removes 4.5.3???? Wtf???
On 07/09/12 14:24, Tanstaafl wrote: This has never happened to me before... Since when did a simple GCC upgrade *automatically* REMOVE my prior GCC install??? I have *always* kept my prior GCC around for a while, if not until the next upgrade, just as something to fall back on if the current one breaks. I am NOT a happy camper. It has always been that way for packages in the same slot. 4.5.3 and 4.5.4 are both in the 4.5 slot. I think you're confusing patch-version upgrades with major and minor-version ones. If you emerge GCC 4.6.3, your 4.5.4 version will be kept. If you really wont to keep multiple patch-versions, then you must set the multislot USE flag for GCC. But unless you have a reason to do that, and it seems you don't, there's no reason to have multiple such versions installed.
[gentoo-user] Re: GCC upgrade from 4.5.3 to 4.5.4 automatically removes 4.5.3???? Wtf???
On 2012-09-07, Tanstaafl tansta...@libertytrek.org wrote: On 2012-09-07 7:44 AM, Markos Chandras hwoar...@gentoo.org wrote: This always happens if the gcc your are upgrading to is in the same slot as the previous one. Well, I've been managing this gentoo server since I installed it over 8 years ago, and I don't *ever* recall a GCC upgrade removing my prior version. And please write proper subject on emails. WTF is not really appropriate for a mailing list. Don't be stupid. I see that all the time... if you don't like it just ignore it. Will do. plonk -- Grant Edwards grant.b.edwardsYow! Here I am in 53 at B.C. and all I want is a gmail.comdill pickle!!
[gentoo-user] Re: gcc upgrade - rebuild everything?
On 10/21/2010 10:58 PM, Grant wrote: I just upgraded from gcc-4.4.3-r2 to gcc-4.4.4-r2 and I'm wondering if I really need to rebuild everything as it says in the guide: http://www.gentoo.org/doc/en/gcc-upgrading.xml All libs of 4.4.3 are binary compatible with 4.4.4. There is no need to rebuild.
[gentoo-user] Re: gcc upgrade: Active gcc profile is invalid!
On 10/21/2010 08:35 PM, Jarry wrote: On 19. 10. 2010 22:07, Neil Bothwick wrote: On Tue, 19 Oct 2010 20:57:18 +0200, Jarry wrote: Especially when I have to repeat it with my 12 gentoo servers. Sequentially, unfortunatally, as they share the same hardware... Why not use --buildpkg the first time and --usepkg the other 11 times? They have slightly different use-flags. But I do not know if some of them might have impact on gcc too... I already mentioned in another post that you don't need to build gcc twice and the message that tells you to do so is wrong.
[gentoo-user] Re: gcc upgrade: Active gcc profile is invalid!
On 10/19/2010 09:57 PM, Jarry wrote: On 19. 10. 2010 20:02, Zeerak Mustafa Waseem wrote: On Tue, Oct 19, 2010 at 07:45:58PM +0200, Jarry wrote: I just tried to upgrade gcc (stable amd64, from 4.4.3-r2 to 4.4.4-r2) following the procedure recommended in Gentoo GCC Upgrade Guide: emerge -uav gcc At the end of compilation, I got these strange messages: * gcc-config: Could not locate 'x86_64-pc-linux-gnu-4.4.3' in '/etc/env.d/gcc/' ! snip * Please re-emerge gcc. * http://bugs.gentoo.org/68395 snip That should do it :) Thanks, emerge --oneshot gcc really seems to have fixed it. What he meant was the link to bugs.gentoo.org, where it is explained that you don't need to do anything and all is fine; the message that tells you to re-emerge gcc is bogus; you do not need to re-emerge it.
Re: [gentoo-user] Re: gcc upgrade
On Wednesday 14 July 2010 06:39:51 Valmor de Almeida wrote: Mark Knecht wrote: On Sat, Jul 10, 2010 at 6:28 AM, Mark Knecht markkne...@gmail.com wrote: On Sat, Jul 10, 2010 at 4:52 AM, Alan McKinnon alan.mckin...@gmail.com wrote: SNIP Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... Precisely... :-) Oh, and besides liking the smell of fresh baked 1 and 0's in the morning emerge -e @world was an easy way to solve my libpng problem. Woke up this morning to a freshly baked Gentoo machine. - Mark One interesting thing on the new Ferrari. If I do - emerge --pretend --verbose --newuse --update --deep world These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB However - emerge -evp world [ebuild U ] x11-proto/scrnsaverproto-1.2.0 [1.1.0] 49 kB [0] [ebuild U ] sys-devel/automake-1.10.3 [1.10.2] 936 kB [0] Total: 536 packages (2 upgrades, 534 reinstalls), Size of downloads: 1,015 kB Portage tree and overlays: [0] /usr/portage [1] /var/lib/layman/science Where - revdep-rebuild --ignore --pretend --verbose * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. and - emerge --depclean --pretend --verbose No packages selected for removal by depclean Packages installed: 538 Packages in world:69 Packages in system: 50 Required packages:538 Number to remove: 0 So emerge -evp is useful to get those last inconsistencies out of the system. You need to read the portage man pages. There is nothing inconsistent about your system and there is nothing to fix. So revdep-rebuild was pointless. Those two packages are BUILD DEPENDS, not RUNTIME DEPENDS. They only need to be upgraded when you emerge something that will use then in the build phase. Portage has had this nice feature for ages. You can switch it off in make.conf -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: gcc upgrade
On Wednesday 14 July 2010 05:49:48 Valmor de Almeida wrote: Mark Knecht wrote: On Sat, Jul 10, 2010 at 6:28 AM, Mark Knecht markkne...@gmail.com wrote: On Sat, Jul 10, 2010 at 4:52 AM, Alan McKinnon alan.mckin...@gmail.com wrote: SNIP Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... Precisely... :-) Oh, and besides liking the smell of fresh baked 1 and 0's in the morning emerge -e @world was an easy way to solve my libpng problem. Woke up this morning to a freshly baked Gentoo machine. - Mark Exactly. My Ferrari is back with a brand new engine and no libpng issue. Lets follow this logic. You blindly wanted to re-emerge all of world because an over-reaching gcc upgrade guide said so. Coincidentally, there was a monumental libpng cock-up hanging around which emerge -e world just happened to fix. And this somehow validates the gcc upgrade guide? You just happened to have a fortunate side-effect at the right time. Doesn't change the fact that the author of the guide wrote a misleading document. -- alan dot mckinnon at gmail dot com
[gentoo-user] Re: gcc upgrade
Alan McKinnon alan.mckin...@gmail.com writes: On Wednesday 14 July 2010 05:49:48 Valmor de Almeida wrote: Mark Knecht wrote: On Sat, Jul 10, 2010 at 6:28 AM, Mark Knecht markkne...@gmail.com wrote: On Sat, Jul 10, 2010 at 4:52 AM, Alan McKinnon alan.mckin...@gmail.com wrote: SNIP Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... Precisely... :-) Oh, and besides liking the smell of fresh baked 1 and 0's in the morning emerge -e @world was an easy way to solve my libpng problem. Woke up this morning to a freshly baked Gentoo machine. - Mark Exactly. My Ferrari is back with a brand new engine and no libpng issue. Lets follow this logic. You blindly wanted to re-emerge all of world because an over-reaching gcc upgrade guide said so. Coincidentally, there was a monumental libpng cock-up hanging around which emerge -e world just happened to fix. And which could have been solved with revdep-rebuild (or at least running it here after removing the previous version solved it - I just followed flameeyes guide). Emerge -e was like buying a new car when it would have been cheaper and easier to just replace the fault part(s). -- Nuno J. Silva gopher://sdf-eu.org/1/users/njsg
Re: [gentoo-user] Re: gcc upgrade
Mark Knecht wrote: On Sat, Jul 10, 2010 at 6:28 AM, Mark Knecht markkne...@gmail.com wrote: On Sat, Jul 10, 2010 at 4:52 AM, Alan McKinnon alan.mckin...@gmail.com wrote: SNIP Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... Precisely... :-) Oh, and besides liking the smell of fresh baked 1 and 0's in the morning emerge -e @world was an easy way to solve my libpng problem. Woke up this morning to a freshly baked Gentoo machine. - Mark Exactly. My Ferrari is back with a brand new engine and no libpng issue. -- Valmor
Re: [gentoo-user] Re: gcc upgrade
Mark Knecht wrote: On Sat, Jul 10, 2010 at 6:28 AM, Mark Knecht markkne...@gmail.com wrote: On Sat, Jul 10, 2010 at 4:52 AM, Alan McKinnon alan.mckin...@gmail.com wrote: SNIP Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... Precisely... :-) Oh, and besides liking the smell of fresh baked 1 and 0's in the morning emerge -e @world was an easy way to solve my libpng problem. Woke up this morning to a freshly baked Gentoo machine. - Mark One interesting thing on the new Ferrari. If I do - emerge --pretend --verbose --newuse --update --deep world These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB However - emerge -evp world [ebuild U ] x11-proto/scrnsaverproto-1.2.0 [1.1.0] 49 kB [0] [ebuild U ] sys-devel/automake-1.10.3 [1.10.2] 936 kB [0] Total: 536 packages (2 upgrades, 534 reinstalls), Size of downloads: 1,015 kB Portage tree and overlays: [0] /usr/portage [1] /var/lib/layman/science Where - revdep-rebuild --ignore --pretend --verbose * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. and - emerge --depclean --pretend --verbose No packages selected for removal by depclean Packages installed: 538 Packages in world:69 Packages in system: 50 Required packages:538 Number to remove: 0 So emerge -evp is useful to get those last inconsistencies out of the system. -- Valmor
Re: [gentoo-user] Re: gcc upgrade
Valmor de Almeida wrote: Mark Knecht wrote: On Sat, Jul 10, 2010 at 6:28 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jul 10, 2010 at 4:52 AM, Alan McKinnonalan.mckin...@gmail.com wrote: SNIP Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... Precisely... :-) Oh, and besides liking the smell of fresh baked 1 and 0's in the morning emerge -e @world was an easy way to solve my libpng problem. Woke up this morning to a freshly baked Gentoo machine. - Mark One interesting thing on the new Ferrari. If I do - emerge --pretend --verbose --newuse --update --deep world These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB However - emerge -evp world [ebuild U ] x11-proto/scrnsaverproto-1.2.0 [1.1.0] 49 kB [0] [ebuild U ] sys-devel/automake-1.10.3 [1.10.2] 936 kB [0] Total: 536 packages (2 upgrades, 534 reinstalls), Size of downloads: 1,015 kB Portage tree and overlays: [0] /usr/portage [1] /var/lib/layman/science Where - revdep-rebuild --ignore --pretend --verbose * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. and - emerge --depclean --pretend --verbose No packages selected for removal by depclean Packages installed: 538 Packages in world:69 Packages in system: 50 Required packages:538 Number to remove: 0 So emerge -evp is useful to get those last inconsistencies out of the system. -- Valmor You can add this option to help with those: --with-bdeps y I consider it -D on steroids. I actually added it to make.conf so that I don't have to type it in each time. Dale :-) :-)
Re: [gentoo-user] Re: gcc upgrade
On Tue, Jul 13, 2010 at 8:50 PM, Dale rdalek1...@gmail.com wrote: Valmor de Almeida wrote: SNIP So emerge -evp is useful to get those last inconsistencies out of the system. -- Valmor You can add this option to help with those: --with-bdeps y I consider it -D on steroids. I actually added it to make.conf so that I don't have to type it in each time. Dale Good catch Dale. I have it in make.conf also - Mark
Re: [gentoo-user] Re: gcc upgrade
Mark Knecht wrote: On Tue, Jul 13, 2010 at 8:50 PM, Dalerdalek1...@gmail.com wrote: Valmor de Almeida wrote: SNIP So emerge -evp is useful to get those last inconsistencies out of the system. -- Valmor You can add this option to help with those: --with-bdeps y I consider it -D on steroids. I actually added it to make.conf so that I don't have to type it in each time. Dale Good catch Dale. I have it in make.conf also - Mark I was the second one to catch that tho. I think it was Alan that told me that when I ran into a similar issue. After a bit we figured out that it was a really deep dependency that was causing me grief. It does take portage longer to calculate dependencies when you add that tho. That little swirling thing goes at it for a while when I do my updates. Then again, it has a lot to think about: Packages installed: 946 Packages in world:78 Packages in system: 50 Required packages:946 I'd be scratching my head too. Dale :-) :-)
Re: [gentoo-user] Re: gcc upgrade
Dale wrote: Valmor de Almeida wrote: Mark Knecht wrote: On Sat, Jul 10, 2010 at 6:28 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jul 10, 2010 at 4:52 AM, Alan McKinnonalan.mckin...@gmail.com wrote: SNIP Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... Precisely... :-) Oh, and besides liking the smell of fresh baked 1 and 0's in the morning emerge -e @world was an easy way to solve my libpng problem. Woke up this morning to a freshly baked Gentoo machine. - Mark One interesting thing on the new Ferrari. If I do - emerge --pretend --verbose --newuse --update --deep world These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB However - emerge -evp world [ebuild U ] x11-proto/scrnsaverproto-1.2.0 [1.1.0] 49 kB [0] [ebuild U ] sys-devel/automake-1.10.3 [1.10.2] 936 kB [0] Total: 536 packages (2 upgrades, 534 reinstalls), Size of downloads: 1,015 kB Portage tree and overlays: [0] /usr/portage [1] /var/lib/layman/science Where - revdep-rebuild --ignore --pretend --verbose * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. and - emerge --depclean --pretend --verbose No packages selected for removal by depclean Packages installed: 538 Packages in world:69 Packages in system: 50 Required packages:538 Number to remove: 0 So emerge -evp is useful to get those last inconsistencies out of the system. -- Valmor You can add this option to help with those: --with-bdeps y I consider it -D on steroids. I actually added it to make.conf so that I don't have to type it in each time. Dale :-) :-) Will use. Thanks, -- Valmor
Re: [gentoo-user] Re: gcc upgrade
In linux.gentoo.user, you wrote: On Saturday 10 July 2010 02:57:42 Nikos Chantziaras wrote: On 07/10/2010 04:16 AM, Valmor de Almeida wrote: Hello, I just updated the portage tree and gcc was upgraded. I have set gcc to the newer version - gcc-config -l [1] i686-pc-linux-gnu-4.3.4 [2] i686-pc-linux-gnu-4.4.3 * and I am trying to rebuild the whole system with emerge -e system emerge -e world assuming this all goes without trouble (will take a while), should I unmerge version 4.3.4? There's no reason to. Unless you don't need it anymore. And why is the OP rebuilding world at all? There's no reason to do that either, there's no API/ABI break between 4.3.4 and 4.3.3 The difference is between 4.3.4 and 4.4.3, not 4.3.3 Gentoo has the new GCC slotted and the handbook http://www.gentoo.org/doc/en/gcc-upgrading.xml Suggests emerge -e system and emerge -e world in the General Upgrade Instructions. If you think the handbook is wrong or my interpretation of it wrong then *please* tell me. I would prefer *not* to go through this nightmare whenever GCC does a major version bump. -- Regards, Gregory. Gentoo Linux - Penguin Power
Re: [gentoo-user] Re: gcc upgrade
On Monday 12 July 2010 10:18:48 zek...@gmail.com wrote: In linux.gentoo.user, you wrote: On Saturday 10 July 2010 02:57:42 Nikos Chantziaras wrote: On 07/10/2010 04:16 AM, Valmor de Almeida wrote: Hello, I just updated the portage tree and gcc was upgraded. I have set gcc to the newer version - gcc-config -l [1] i686-pc-linux-gnu-4.3.4 [2] i686-pc-linux-gnu-4.4.3 * and I am trying to rebuild the whole system with emerge -e system emerge -e world assuming this all goes without trouble (will take a while), should I unmerge version 4.3.4? There's no reason to. Unless you don't need it anymore. And why is the OP rebuilding world at all? There's no reason to do that either, there's no API/ABI break between 4.3.4 and 4.3.3 The difference is between 4.3.4 and 4.4.3, not 4.3.3. Typo. Gentoo has the new GCC slotted and the handbook Of course is slotted. gcc has been slotted since the dawn of time so that you can install mutiple compilers and use any one you feel like at any point. Tools exists to switch the current compiler in use http://www.gentoo.org/doc/en/gcc-upgrading.xml Suggests emerge -e system and emerge -e world in the General Upgrade Instructions. It suggests, it does not say it is mandatory with description of why. Periodically on this list this topic comes up and we re-hash again, for the unmpteenth time, why the docs are misleading. That doc was apparently written by someone who was looking for ways to minimize the amount of mail he gets. If he says to rebuild system and world, then most of the questions he gets asked just go away. Can't fault the dev for that This is all in the mail archives. Most of the whinging done by me actually If you think the handbook is wrong or my interpretation of it wrong then *please* tell me. I would prefer *not* to go through this nightmare whenever GCC does a major version bump. You do not have to do what the handbook tells you, you just have to realise what the handbook hopes to achieve. As hinted above, the intended result appears to be least hassle for the gentoo devs and document writers with maximal guarantee that your box will work afterwards regardless fo how long it takes or number of cpu cycles burnt. It's not necessarily the most convenient way. I have not had to rebuild world due to a compiler upgrade since sometime around the late 3 series (there was a C++ ABI change). -- alan dot mckinnon at gmail dot com
[gentoo-user] Re: gcc upgrade
Alan McKinnon alan.mckin...@gmail.com writes: On Monday 12 July 2010 10:18:48 zek...@gmail.com wrote: In linux.gentoo.user, you wrote: On Saturday 10 July 2010 02:57:42 Nikos Chantziaras wrote: On 07/10/2010 04:16 AM, Valmor de Almeida wrote: Hello, I just updated the portage tree and gcc was upgraded. I have set gcc to the newer version - gcc-config -l [1] i686-pc-linux-gnu-4.3.4 [2] i686-pc-linux-gnu-4.4.3 * and I am trying to rebuild the whole system with emerge -e system emerge -e world assuming this all goes without trouble (will take a while), should I unmerge version 4.3.4? There's no reason to. Unless you don't need it anymore. And how do we know that? I, myself, wonder, as the previous version here is picked by depclean for removal. Can we trust depclean? I suppose if a package didn't compile and had no explicit dependency on the gcc version, that would be a good reason for a bug report and an ebuild change. http://www.gentoo.org/doc/en/gcc-upgrading.xml Suggests emerge -e system and emerge -e world in the General Upgrade Instructions. It suggests, it does not say it is mandatory with description of why. Periodically on this list this topic comes up and we re-hash again, for the unmpteenth time, why the docs are misleading. That doc was apparently written by someone who was looking for ways to minimize the amount of mail he gets. If he says to rebuild system and world, then most of the questions he gets asked just go away. Can't fault the dev for that Warning: following this handbook might lead to an infinite loop, when you sync after recompiling everything and you find a newer gcc version was marked stable, and you have to start again. If keeping both versions prevents the troubles fixed by recompiling everything, then it's just not worth it removing the old version (unless you own really fast machine). Suggesting emerge -e is anyway a possible solution for problems, just not the one to choose first. Can't we rely on revdep-rebuild, or write something to catch known upgrade issues? It sounds a while not okay run revdep-rebuild would be a better solution (but I don't know whether revdep-rebuild catches the issues --- probably not if there is an interface change but the library uses the same name as before...). This is all in the mail archives. Most of the whinging done by me actually If you think the handbook is wrong or my interpretation of it wrong then *please* tell me. I would prefer *not* to go through this nightmare whenever GCC does a major version bump. You do not have to do what the handbook tells you, you just have to realise what the handbook hopes to achieve. As hinted above, the intended result appears to be least hassle for the gentoo devs and document writers with maximal guarantee that your box will work afterwards regardless fo how long it takes or number of cpu cycles burnt. It's not necessarily the most convenient way. I have not had to rebuild world due to a compiler upgrade since sometime around the late 3 series (there was a C++ ABI change). The one which involved emerging libstdc++-v3, and which rendered the whole system unusable due to a chicken and an egg? -- Nuno J. Silva gopher://sdf-eu.org/1/users/njsg
Re: [gentoo-user] Re: gcc upgrade
On Fri, 09 Jul 2010 20:02:23 -0500, Dale wrote: assuming this all goes without trouble (will take a while), should I unmerge version 4.3.4? There's no reason to. Unless you don't need it anymore. Or he doesn't like cruft or needs the drive space. Is rebuilding the whole system needed for that upgrade tho? Only if you want to remove the old version, if only to ensure that everything builds with 4.4. Every time I remove 4.3, I find myself re-emerging it because some odd package won't build with 4.4, so I ended up leaving it there. -- Neil Bothwick Last words of a Windows user: = Why does that work now? signature.asc Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade
On Saturday 10 July 2010 02:57:42 Nikos Chantziaras wrote: On 07/10/2010 04:16 AM, Valmor de Almeida wrote: Hello, I just updated the portage tree and gcc was upgraded. I have set gcc to the newer version - gcc-config -l [1] i686-pc-linux-gnu-4.3.4 [2] i686-pc-linux-gnu-4.4.3 * and I am trying to rebuild the whole system with emerge -e system emerge -e world assuming this all goes without trouble (will take a while), should I unmerge version 4.3.4? There's no reason to. Unless you don't need it anymore. And why is the OP rebuilding world at all? There's no reason to do that either, there's no API/ABI break between 4.3.4 and 4.3.3 Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: gcc upgrade
On Sat, Jul 10, 2010 at 4:52 AM, Alan McKinnon alan.mckin...@gmail.com wrote: SNIP Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... Precisely... :-)
Re: [gentoo-user] Re: gcc upgrade
On Sat, Jul 10, 2010 at 6:28 AM, Mark Knecht markkne...@gmail.com wrote: On Sat, Jul 10, 2010 at 4:52 AM, Alan McKinnon alan.mckin...@gmail.com wrote: SNIP Unless he's the kind of guy who likes to rip his Ferrari apart for kicks and put it all back together again so that not even the factory can notice... Precisely... :-) Oh, and besides liking the smell of fresh baked 1 and 0's in the morning emerge -e @world was an easy way to solve my libpng problem. Woke up this morning to a freshly baked Gentoo machine. - Mark
Re: [gentoo-user] Re: gcc upgrade
* Mark Knecht markkne...@gmail.com wrote: Oh, and besides liking the smell of fresh baked 1 and 0's in the morning emerge -e @world was an easy way to solve my libpng problem. Woke up this morning to a freshly baked Gentoo machine. Now we just need support for emerging fresh and hot coffee ;-) BTW: regularily emerging world could be a fine testbed. Maybe I'll set up an chroot or container for that on some idling boxes ... cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
[gentoo-user] Re: gcc upgrade
On 07/10/2010 04:16 AM, Valmor de Almeida wrote: Hello, I just updated the portage tree and gcc was upgraded. I have set gcc to the newer version - gcc-config -l [1] i686-pc-linux-gnu-4.3.4 [2] i686-pc-linux-gnu-4.4.3 * and I am trying to rebuild the whole system with emerge -e system emerge -e world assuming this all goes without trouble (will take a while), should I unmerge version 4.3.4? There's no reason to. Unless you don't need it anymore.
Re: [gentoo-user] Re: gcc upgrade
On Fri, Jul 9, 2010 at 6:02 PM, Dale rdalek1...@gmail.com wrote: Nikos Chantziaras wrote: On 07/10/2010 04:16 AM, Valmor de Almeida wrote: Hello, I just updated the portage tree and gcc was upgraded. I have set gcc to the newer version - gcc-config -l [1] i686-pc-linux-gnu-4.3.4 [2] i686-pc-linux-gnu-4.4.3 * and I am trying to rebuild the whole system with emerge -e system emerge -e world assuming this all goes without trouble (will take a while), should I unmerge version 4.3.4? There's no reason to. Unless you don't need it anymore. Or he doesn't like cruft or needs the drive space. Is rebuilding the whole system needed for that upgrade tho? Dale :-) :-) Not needed but I'm doing it. - Mark
Re: [gentoo-user] Re: gcc upgrade
Dale wrote: [snip] Is rebuilding the whole system needed for that upgrade tho? Dale :-) :-) Thought it would be a good idea to have a consistent system; not sure whether it is necessary. Thanks for the replies. -- Valmor
Re: [gentoo-user] Re: gcc upgrade
Mark Knecht wrote: On Fri, Jul 9, 2010 at 6:02 PM, Dalerdalek1...@gmail.com wrote: Nikos Chantziaras wrote: On 07/10/2010 04:16 AM, Valmor de Almeida wrote: Hello, I just updated the portage tree and gcc was upgraded. I have set gcc to the newer version -gcc-config -l [1] i686-pc-linux-gnu-4.3.4 [2] i686-pc-linux-gnu-4.4.3 * and I am trying to rebuild the whole system with emerge -e system emerge -e world assuming this all goes without trouble (will take a while), should I unmerge version 4.3.4? There's no reason to. Unless you don't need it anymore. Or he doesn't like cruft or needs the drive space. Is rebuilding the whole system needed for that upgrade tho? Dale :-) :-) Not needed but I'm doing it. - Mark I'm not going to tell you not to. I usually do at least a emerge -e system myself. I at least want to make certain I can boot up. I'm not fond of doing the chroot thing. :/ Hope everything compiles fine. Dale :-) :-)
Re: [gentoo-user] Re: gcc upgrade
On Fri, Jul 9, 2010 at 7:26 PM, Dale rdalek1...@gmail.com wrote: Mark Knecht wrote: On Fri, Jul 9, 2010 at 6:02 PM, Dalerdalek1...@gmail.com wrote: Nikos Chantziaras wrote: On 07/10/2010 04:16 AM, Valmor de Almeida wrote: Hello, I just updated the portage tree and gcc was upgraded. I have set gcc to the newer version - gcc-config -l [1] i686-pc-linux-gnu-4.3.4 [2] i686-pc-linux-gnu-4.4.3 * and I am trying to rebuild the whole system with emerge -e system emerge -e world assuming this all goes without trouble (will take a while), should I unmerge version 4.3.4? There's no reason to. Unless you don't need it anymore. Or he doesn't like cruft or needs the drive space. Is rebuilding the whole system needed for that upgrade tho? Dale :-) :-) Not needed but I'm doing it. - Mark I'm not going to tell you not to. I usually do at least a emerge -e system myself. I at least want to make certain I can boot up. I'm not fond of doing the chroot thing. :/ Hope everything compiles fine. Dale I got tired of dealing with my libpng problem by hand. I kicked off an emerge -e @world in hopes that I'll just come back in a few hours to a fixed up system. We'll see - Mark
[gentoo-user] Re: gcc upgrade
On 07/09/2010 07:45 PM, Valmor de Almeida wrote: Dale wrote: [snip] Is rebuilding the whole system needed for that upgrade tho? Dale :-) :-) Thought it would be a good idea to have a consistent system; not sure whether it is necessary. Thanks for the replies. The only real need to re-emerge packages is if the new gcc version updates your version of libstdc++, because that lib is supplied by each new version of the gcc package: $ls -l /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libstdc++* -rw-r--r-- 1 root root 2237388 2010-06-06 13:16 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libstdc++.a lrwxrwxrwx 1 root root 19 2010-06-06 13:17 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libstdc++.so - libstdc++.so.6.0.13* lrwxrwxrwx 1 root root 19 2010-06-06 13:17 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libstdc++.so.6 - libstdc++.so.6.0.13* -rwxr-xr-x 1 root root 954472 2010-06-06 13:16 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libstdc++.so.6.0.13* -rw-r--r-- 1 root root 2384572 2010-06-06 13:16 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libstdc++_pic.a The only packages on your machine that would be affected by the gcc update are those packages that are linked against the OLD version of libstdc++.so. Running revdep-rebuild should rebuild/reinstall all of those packages. Theoretically speaking, of course :)
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Ryan Tandy wrote: Dale wrote: Cheese, I'm learning something. I already knew that it would not delete files in /etc/ and now I know why. LOL I never put the two together before you said that. Well, the /etc thing is generally more due to CONFIG_PROTECT - it won't delete files from /etc regardless of whether or not you've modified them, because they're under CONFIG_PROTECTion. Yea, but now I know that. Sometimes it takes my light bulb a while to get brightened up good. :-( LOL Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Fri, 08 Sep 2006 23:15:09 -0500, Dale wrote: So basically if I mess with a file and then unmerge the program it belongs to, I have to remember which ones I messed with and delete them myself? Yes, because the file is no longer the file portage installed, so it has no right to remove it. If I unmerge this in a console and can't read all the -- !mtime as they roll by, I'm stuck with orphan files on my rig? This needs a fix but I wouldn't want to be the dev to figure this one out. ;-) This generally isn't a problem, because you normally only edit files in /etc, which are config protected anyway. It arises here because fix_libtool_files.sh modifies the .la files. One could argue that it is the responsibility of that script to check the md5/mtime information and update it. -- Neil Bothwick A computer scientist is someone who, when told to Go to Hell, sees the go to, rather than the destination, as harmful. signature.asc Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Neil Bothwick wrote: On Fri, 08 Sep 2006 23:15:09 -0500, Dale wrote: So basically if I mess with a file and then unmerge the program it belongs to, I have to remember which ones I messed with and delete them myself? Yes, because the file is no longer the file portage installed, so it has no right to remove it. If I unmerge this in a console and can't read all the -- !mtime as they roll by, I'm stuck with orphan files on my rig? This needs a fix but I wouldn't want to be the dev to figure this one out. ;-) This generally isn't a problem, because you normally only edit files in /etc, which are config protected anyway. It arises here because fix_libtool_files.sh modifies the .la files. One could argue that it is the responsibility of that script to check the md5/mtime information and update it. Cheese, I'm learning something. I already knew that it would not delete files in /etc/ and now I know why. LOL I never put the two together before you said that. Who knows, maybe in 20 years I'll be a dev. O_O I'll be too old then though. I'm working on a fresh install on another hard drive now. That will clear out some cruft. I copied my make.conf file and one other config file and that is it. Oh, the kernel's .config. I knew it was something outside of /etc. Thanks for clearing up my muddy water. Care to help with the rest now? LOL Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Monday 11 September 2006 23:32, Neil Bothwick wrote: On Fri, 08 Sep 2006 23:15:09 -0500, Dale wrote: So basically if I mess with a file and then unmerge the program it belongs to, I have to remember which ones I messed with and delete them myself? Yes, because the file is no longer the file portage installed, so it has no right to remove it. [SNIP] This generally isn't a problem, because you normally only edit files in /etc, which are config protected anyway. It arises here because fix_libtool_files.sh modifies the .la files. I still would prefer if it was stored in a log file somewhere so that if I ever stumple upon it I can see where it came from... Haven't gotten around to filing any bug about that though. One could argue that it is the responsibility of that script to check the md5/mtime information and update it. http://bugs.gentoo.org/show_bug.cgi?id=71265 -- Bo Andresen pgpgShGE4HY4O.pgp Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Dale wrote: Cheese, I'm learning something. I already knew that it would not delete files in /etc/ and now I know why. LOL I never put the two together before you said that. Well, the /etc thing is generally more due to CONFIG_PROTECT - it won't delete files from /etc regardless of whether or not you've modified them, because they're under CONFIG_PROTECTion. -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
[EMAIL PROTECTED] schrieb: I'm upgrading my gcc from 3.x to 4.x. I've done the gcc switching, and now I'm updating my system. The recommended steps are: # emerge -eav system # emerge -eav world While emerging my system I received a message suggesting I run revdep-rebuild: warning - be sure to run revdep-rebuild now My question is, should I run revdep-rebuild right after emerging the system, or should I wait until after I emerge world? My concern was that in between, my system is in an unstable intermediate state, and it might be damaged by a revdep-rebuild in between. Well, you rebuild world, which includes all packages you would rebuild with revdep-rebuild. I would run revdep-rebuild after the rebuild of world, just to be sure. I also recommend to look through the info outputs of every emerge, if you missed something, e.g. I had messages like rebuild against the new library, than it is save to delete the old one. If you miss this, then you have cruft libs on your system. Cheers Marc -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Marc Blumentritt wrote: snip I would run revdep-rebuild after the rebuild of world, just to be sure. snip Cheers Marc I did that too. I'm not sure if it is just me or what but every time I run revdep-rebuild it wants to emerge gcc again. It did the same thing before the gcc upgrade. If you run it, you may want to post to make sure it is making sense. After three runs, I said forget it. It'll just have to keep. I read somewhere it was a bug. I dunno. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Dale schrieb: Marc Blumentritt wrote: I did that too. I'm not sure if it is just me or what but every time I run revdep-rebuild it wants to emerge gcc again. It did the same thing before the gcc upgrade. If you run it, you may want to post to make sure it is making sense. After three runs, I said forget it. It'll just have to keep. I read somewhere it was a bug. I dunno. Did you remove the temporary files of revdep-rebuild from /root? I had no problems with the upgrade and running revdep-rebuild afterward. In fact, revdep-rebuild showed me no package at all to rebuild, which was what I expected. Cheers Marc -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Friday 08 September 2006 15:00, Dale wrote: I'm not sure if it is just me or what but every time I run revdep-rebuild it wants to emerge gcc again. It did the same thing before the gcc upgrade. It is bug #125728 [1]? Otherwise if it continues consider posting the output of: # revdep-rebuild -i -- -vp [1] http://bugs.gentoo.org/show_bug.cgi?id=125728 -- Bo Andresen pgp80mi9wtzxM.pgp Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Marc Blumentritt wrote: Dale schrieb: Marc Blumentritt wrote: I did that too. I'm not sure if it is just me or what but every time I run revdep-rebuild it wants to emerge gcc again. It did the same thing before the gcc upgrade. If you run it, you may want to post to make sure it is making sense. After three runs, I said forget it. It'll just have to keep. I read somewhere it was a bug. I dunno. Did you remove the temporary files of revdep-rebuild from /root? I had no problems with the upgrade and running revdep-rebuild afterward. In fact, revdep-rebuild showed me no package at all to rebuild, which was what I expected. Cheers Marc I remove those each time. It is sort of a habit now. I run it on occasion especially if I remove something. Just to make sure. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On 9/8/06, Dale [EMAIL PROTECTED] wrote: Checking dynamic linking consistency... broken /usr/lib/aqbanking/plugins/0/bankinfo/de.la (requires /usr/lib/libaqbanking.la) Since you don't have aqbanking installed anymore, just delete these files, and probably the entire /usr/lib/qabanking directory. Might want to run an equery belongs /usr/lib/aqbanking first just to make sure nothing claims ownership of those files first... broken /usr/lib/avifile-0.7/ac3pass.la (requires /usr/lib/libaviplayavformat.la) broken /usr/lib/avifile-0.7/ac3pass.la (requires ... I suspect this is the same as aqbanking..no longer installed, so same solution. Equery belongs to be sure... broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgij.la (requires /usr/lib/libgcj.la) Definitely bug #125728. I believe comment #29 contains the best workarounds until a fix is actually applied. broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires /usr/kde/3.4/lib/libkio.la) ... Here again, equery belongs /usr/lib/kde3/libk3blibsndfiledecoder.la. If nothing owns it, just remove it. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Fri, 08 Sep 2006 16:14:53 -0500, Dale wrote: broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavformat.la) broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavcodec.la) broken /usr/lib/libqbanking.la (requires /usr/lib/libaqbanking.la) broken /usr/lib/libqbanking.la (requires /usr/lib/libgwenhywfar.la) [repeated] I unmerged aqbanking. It wouldn't compile and I was not using it anyway. What you think? Bug or me having a setting wrong?? Did you run fix_libtool_files.sh between merging and unmerging aqbanking? This changes .la files, which means that their checksums no longer match the installed versions so portage doesn't remove them. Whether this is a bug in fix_libtool_files.sh or portage is open for discussion. -- Neil Bothwick When companies ship Styrofoam, what do they pack it in? signature.asc Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On 9/8/06, Dale [EMAIL PROTECTED] wrote: So basically if these files don't belong to anything, I can safely delete them? Yep. On the roach report, me sort of chicken to edit those files. Will it be OK to let it stay like this and let the bug get fixed? It's been doing this a while and I don't !see! any problems. Yes, as long as you don't mind the revdep-rebuild borkage. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Bo Ørsted Andresen wrote: I'm working on the list above. So far nothing belongs to anything. Maybe I need a depclean on this thing. It is a 3 year old install if I recall correctly. This has nothing to do with depclean. Neils suggesting that the md5sums were altered by fix_libtool_files.sh and hence not removed seems much more likely. Portage doesn't removed files with altered md5sums.. What would be a good way of finding files that were not deleted when something was upgraded/unmerged? I thought depclean was different from what I wanted to say but it got the ball rolling. Last part, zm, right over my head I think. Let's see if I get this right. emerge put a file in there, something, me maybe, changed something so it leaves it alone. That right?? Gosh I wish someone could just pour all the Gentoo stuff in my head. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Saturday 09 September 2006 05:33, Dale wrote: What would be a good way of finding files that were not deleted when something was upgraded/unmerged? I thought depclean was different from what I wanted to say but it got the ball rolling. Depclean is to remove packages that are no longer in or a dependency of something in your world file. Last part, zm, right over my head I think. Let's see if I get this right. emerge put a file in there, something, me maybe, changed something so it leaves it alone. That right?? Yep. So just to illustrate: # touch /usr/share/vim/vimfiles/plugin/bugsummary.vim # emerge --unmerge -va gentoo-syntax These are the packages that would be unmerged: [SNIP] Unmerging app-vim/gentoo-syntax-20051221-r1... No package files given... Grabbing a set. [SNIP] obj /usr/share/vim/vimfiles/plugin/newinitd.vim obj /usr/share/vim/vimfiles/plugin/neweselect.vim obj /usr/share/vim/vimfiles/plugin/newebuild.vim obj /usr/share/vim/vimfiles/plugin/gentoo-common.vim --- !mtime obj /usr/share/vim/vimfiles/plugin/bugsummary.vim [SNIP] --- !empty dir /usr/share/vim dir /usr/share/doc/gentoo-syntax-20051221-r1 All the things that has a are actually removed. The things with --- are not removed for the reason given in the following column. Since I touch'ed /usr/share/vim/vimfiles/plugin/bugsummary.vim it wasn't removed with the reason: !mtime which means the last modified time has been altered after it was installed. The reason !empty is the reason for dirs which aren't empty (others packages have installed files in the same dirs...). After the unmerge is complete the only way to know is that the files no longer belong to any package. Of course when I remerge this package in a few minutes the files will be overwritten and the mtime will be correct again... Hope that makes it clear. -- Bo Andresen pgpO8wwWjx1D1.pgp Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Bo Ørsted Andresen wrote: On Saturday 09 September 2006 05:33, Dale wrote: What would be a good way of finding files that were not deleted when something was upgraded/unmerged? I thought depclean was different from what I wanted to say but it got the ball rolling. Depclean is to remove packages that are no longer in or a dependency of something in your world file. Last part, zm, right over my head I think. Let's see if I get this right. emerge put a file in there, something, me maybe, changed something so it leaves it alone. That right?? Yep. So just to illustrate: # touch /usr/share/vim/vimfiles/plugin/bugsummary.vim # emerge --unmerge -va gentoo-syntax These are the packages that would be unmerged: [SNIP] Unmerging app-vim/gentoo-syntax-20051221-r1... No package files given... Grabbing a set. [SNIP] obj /usr/share/vim/vimfiles/plugin/newinitd.vim obj /usr/share/vim/vimfiles/plugin/neweselect.vim obj /usr/share/vim/vimfiles/plugin/newebuild.vim obj /usr/share/vim/vimfiles/plugin/gentoo-common.vim --- !mtime obj /usr/share/vim/vimfiles/plugin/bugsummary.vim [SNIP] --- !empty dir /usr/share/vim dir /usr/share/doc/gentoo-syntax-20051221-r1 All the things that has a are actually removed. The things with --- are not removed for the reason given in the following column. Since I touch'ed /usr/share/vim/vimfiles/plugin/bugsummary.vim it wasn't removed with the reason: !mtime which means the last modified time has been altered after it was installed. The reason !empty is the reason for dirs which aren't empty (others packages have installed files in the same dirs...). After the unmerge is complete the only way to know is that the files no longer belong to any package. Of course when I remerge this package in a few minutes the files will be overwritten and the mtime will be correct again... Hope that makes it clear. So basically if I mess with a file and then unmerge the program it belongs to, I have to remember which ones I messed with and delete them myself? If I unmerge this in a console and can't read all the -- !mtime as they roll by, I'm stuck with orphan files on my rig? This needs a fix but I wouldn't want to be the dev to figure this one out. ;-) Dale :-) :-) -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: gcc Upgrade Problem
[EMAIL PROTECTED] writes: Hi, At the end of that same quide there're some hints on most common errors. So to just continue on with the recompile run:#emerge --resume --skipfirst. But that will work only if no other emerge command was run in between. Later you could investigate about this error. It seems it just a matter of choosing the right way to authenticate. HTH.Rumen -- Thanks for the response. I figured this out on my own. Duh, Colleen ... Try what the error messages say and read farther down in the documentation - you might get a hint! -- This is me talking to myself. I made the changes suggested by the error messages and did find that further down in the Guide it specified how to continue. The build continued and I've been building the remaining packages for a couple of hours now without any problems. I'm still getting used to and am constantly amazed at how good Gentoo documentation is. :-) Sorry for troubling the list! Regards, Colleen -- gentoo-user@gentoo.org mailing list
