Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Sat, Dec 20, 2014 at 9:04 PM, meino.cra...@gmx.de wrote: Matti Nykyri matti.nyk...@iki.fi [14-12-20 19:48]: On Dec 20, 2014, at 17:56, meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-20 02:47]: meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-19 17:08]: Mick wrote: Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. I don't recall ever running fix_libtool_files.sh after switching gcc versions. Usually when I see a gcc upgrade, I emerge it, switch to it and the usual profile thing, run emerge -e world JUST to be safe, then unmerge the old gcc. That's all I usually do here. I have skipped the emerge -e world a time or two. Am I just lucky, not likely as some may know, or does emerge -e world catch it or what? Now I'm curious. Dale :-) :-) Hi Dale, I started compiling the new gcc this morning about ~7:00 AM...just a few minutes ago stage3 finishes. Now ... before doing anything else... I am makeing a backup of all that, so...if anything fails...I am able to reinstall the status quo. I will keep you informed, what happens to my little embedded system... Best Meino That's the thing about slow systems, you want to do it right the first time because it takes to much time to repeat something. Heck, I have a 4 core AMD CPU with 16GBs of ram here and I still would rather do it right the first time. If you have something slow that takes days to do something, you really want plan A to work. I'm also wondering if there have been changes to emerge that could make a difference. I run the latest unstable non * version. I sorta like having all the new improvements. I'm just not sure if that affects the issue here is all. Dale :-) :-) Hi, after a few more non-booting-systems and backup-reinstalls I think I know whats the reason is...but by I dont know how to get out of it: The system becomes inaccessible if I do an env-update and reboot. Reason for that are binaries, in which the path to the old gcc is hardcoded. With the sdcard mounted I checked that with my PC: I did a grep -r '\/usr\/lib\/gcc\/armv7a-hardfloat-linux-gnueabi\/4.7.3' on ALL files of the sdcard and found thousands of hardcoded links to the old gcc inside binaries... The new gcc installed but not doing env-update implies that any further compilation will link to the old gcc. Doing env-update implies a system which will not survive the next reboot. What now? If i understand your situation correctly, do: gcc-config to set the new version env-update logout login emerge --deep --update world emerge --depclean revdep-rebuild This will take a long time but will get your system working again. If you don't wan't to do that you can of course tweak the libraries with binary tools. That is easy if you know what you are doing. To prevent this in the future always before world update, update gcc and glibc first if tere is a new version available. Gcc-config is crusial after you have installed a bew version of gcc. -- -Matti Hi Matti, not exactly... The sequence you show looks like this in my case: gcc-config to set the new version env-update reboot logina attempt: impossible...system does not respond anymore The reason is, that env-update updates to the new compiler, while some [CENSORED] system tools/application are hardcoded to use the old compiler libraries... If I do a env-update --no-ldconfig then I am able to reboot successfully...but compilation will be done against the old compiler a fear... I am installing the backup the fourth time today and I am curious, when the first bad sectors of my sdcard will hit me... Best regards, Meino Im surprised no one has suggested this, but have you tried running: emerge --oneshot libtool after gcc-config and before env-update source /etc/profile? This is the advice that is given in the wiki [https://wiki.gentoo.org/wiki/Upgrading_GCC] and it has worked for me so far. It also says that running `fix_libtool_files.sh` manually is not necessary as it is run during the emerge automatically.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 December 2014 19:23:36 meino.cra...@gmx.de wrote: backup done! now... gcc-4.8.3 is installed, gcc-config points to the new compiler, the environment is updated (I logged out and in again) and I checked /etc/env.d/04gcc-armv7a-hardfloat-linux-gnueabi for using the new compiler. So everything is fine...except... You don't mention env-update. You should do that explicitly - logging out and in won't do it. If I [removed] the old compiler now, my system would again be broken. ---8 How to proceed now? I'd start again from just after emerging the new version of GCC. -- Rgds Peter.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 December 2014 17:20:17 meino.cra...@gmx.de wrote: I will keep you informed, what happens to my little embedded system... Ah. I have a couple of chroots on my workstation for compiling packages for small boxes. I suggest you do the same. As long as you know all the right USE flags, etc., it should be much quicker to build the system in the chroot, then rsync /usr/portage to the target box and install from packages. -- Rgds Peter.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
Dale rdalek1...@gmail.com [14-12-20 02:47]: meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-19 17:08]: Mick wrote: Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. I don't recall ever running fix_libtool_files.sh after switching gcc versions. Usually when I see a gcc upgrade, I emerge it, switch to it and the usual profile thing, run emerge -e world JUST to be safe, then unmerge the old gcc. That's all I usually do here. I have skipped the emerge -e world a time or two. Am I just lucky, not likely as some may know, or does emerge -e world catch it or what? Now I'm curious. Dale :-) :-) Hi Dale, I started compiling the new gcc this morning about ~7:00 AM...just a few minutes ago stage3 finishes. Now ... before doing anything else... I am makeing a backup of all that, so...if anything fails...I am able to reinstall the status quo. I will keep you informed, what happens to my little embedded system... Best Meino That's the thing about slow systems, you want to do it right the first time because it takes to much time to repeat something. Heck, I have a 4 core AMD CPU with 16GBs of ram here and I still would rather do it right the first time. If you have something slow that takes days to do something, you really want plan A to work. I'm also wondering if there have been changes to emerge that could make a difference. I run the latest unstable non * version. I sorta like having all the new improvements. I'm just not sure if that affects the issue here is all. Dale :-) :-) Hi, after a few more non-booting-systems and backup-reinstalls I think I know whats the reason is...but by I dont know how to get out of it: The system becomes inaccessible if I do an env-update and reboot. Reason for that are binaries, in which the path to the old gcc is hardcoded. With the sdcard mounted I checked that with my PC: I did a grep -r '\/usr\/lib\/gcc\/armv7a-hardfloat-linux-gnueabi\/4.7.3' on ALL files of the sdcard and found thousands of hardcoded links to the old gcc inside binaries... The new gcc installed but not doing env-update implies that any further compilation will link to the old gcc. Doing env-update implies a system which will not survive the next reboot. What now? Best regards, Meino
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Dec 20, 2014, at 17:56, meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-20 02:47]: meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-19 17:08]: Mick wrote: Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. I don't recall ever running fix_libtool_files.sh after switching gcc versions. Usually when I see a gcc upgrade, I emerge it, switch to it and the usual profile thing, run emerge -e world JUST to be safe, then unmerge the old gcc. That's all I usually do here. I have skipped the emerge -e world a time or two. Am I just lucky, not likely as some may know, or does emerge -e world catch it or what? Now I'm curious. Dale :-) :-) Hi Dale, I started compiling the new gcc this morning about ~7:00 AM...just a few minutes ago stage3 finishes. Now ... before doing anything else... I am makeing a backup of all that, so...if anything fails...I am able to reinstall the status quo. I will keep you informed, what happens to my little embedded system... Best Meino That's the thing about slow systems, you want to do it right the first time because it takes to much time to repeat something. Heck, I have a 4 core AMD CPU with 16GBs of ram here and I still would rather do it right the first time. If you have something slow that takes days to do something, you really want plan A to work. I'm also wondering if there have been changes to emerge that could make a difference. I run the latest unstable non * version. I sorta like having all the new improvements. I'm just not sure if that affects the issue here is all. Dale :-) :-) Hi, after a few more non-booting-systems and backup-reinstalls I think I know whats the reason is...but by I dont know how to get out of it: The system becomes inaccessible if I do an env-update and reboot. Reason for that are binaries, in which the path to the old gcc is hardcoded. With the sdcard mounted I checked that with my PC: I did a grep -r '\/usr\/lib\/gcc\/armv7a-hardfloat-linux-gnueabi\/4.7.3' on ALL files of the sdcard and found thousands of hardcoded links to the old gcc inside binaries... The new gcc installed but not doing env-update implies that any further compilation will link to the old gcc. Doing env-update implies a system which will not survive the next reboot. What now? If i understand your situation correctly, do: gcc-config to set the new version env-update logout login emerge --deep --update world emerge --depclean revdep-rebuild This will take a long time but will get your system working again. If you don't wan't to do that you can of course tweak the libraries with binary tools. That is easy if you know what you are doing. To prevent this in the future always before world update, update gcc and glibc first if tere is a new version available. Gcc-config is crusial after you have installed a bew version of gcc. -- -Matti
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
Matti Nykyri matti.nyk...@iki.fi [14-12-20 19:48]: On Dec 20, 2014, at 17:56, meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-20 02:47]: meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-19 17:08]: Mick wrote: Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. I don't recall ever running fix_libtool_files.sh after switching gcc versions. Usually when I see a gcc upgrade, I emerge it, switch to it and the usual profile thing, run emerge -e world JUST to be safe, then unmerge the old gcc. That's all I usually do here. I have skipped the emerge -e world a time or two. Am I just lucky, not likely as some may know, or does emerge -e world catch it or what? Now I'm curious. Dale :-) :-) Hi Dale, I started compiling the new gcc this morning about ~7:00 AM...just a few minutes ago stage3 finishes. Now ... before doing anything else... I am makeing a backup of all that, so...if anything fails...I am able to reinstall the status quo. I will keep you informed, what happens to my little embedded system... Best Meino That's the thing about slow systems, you want to do it right the first time because it takes to much time to repeat something. Heck, I have a 4 core AMD CPU with 16GBs of ram here and I still would rather do it right the first time. If you have something slow that takes days to do something, you really want plan A to work. I'm also wondering if there have been changes to emerge that could make a difference. I run the latest unstable non * version. I sorta like having all the new improvements. I'm just not sure if that affects the issue here is all. Dale :-) :-) Hi, after a few more non-booting-systems and backup-reinstalls I think I know whats the reason is...but by I dont know how to get out of it: The system becomes inaccessible if I do an env-update and reboot. Reason for that are binaries, in which the path to the old gcc is hardcoded. With the sdcard mounted I checked that with my PC: I did a grep -r '\/usr\/lib\/gcc\/armv7a-hardfloat-linux-gnueabi\/4.7.3' on ALL files of the sdcard and found thousands of hardcoded links to the old gcc inside binaries... The new gcc installed but not doing env-update implies that any further compilation will link to the old gcc. Doing env-update implies a system which will not survive the next reboot. What now? If i understand your situation correctly, do: gcc-config to set the new version env-update logout login emerge --deep --update world emerge --depclean revdep-rebuild This will take a long time but will get your system working again. If you don't wan't to do that you can of course tweak the libraries with binary tools. That is easy if you know what you are doing. To prevent this in the future always before world update, update gcc and glibc first if tere is a new version available. Gcc-config is crusial after you have installed a bew version of gcc. -- -Matti Hi Matti, not exactly... The sequence you show looks like this in my case: gcc-config to set the new version env-update reboot logina attempt: impossible...system does not respond anymore The reason is, that env-update updates to the new compiler, while some [CENSORED] system tools/application are hardcoded to use the old compiler libraries... If I do a env-update --no-ldconfig then I am able to reboot successfully...but compilation will be done against the old compiler a fear... I am installing the backup the fourth time today and I am curious, when the first bad sectors of my sdcard will hit me... Best regards, Meino
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Dec 20, 2014, at 21:04, meino.cra...@gmx.de wrote: Hi Matti, not exactly... The sequence you show looks like this in my case: gcc-config to set the new version env-update reboot logina attempt: impossible...system does not respond anymore Did I miss something or why do you reboot in that phase? -- -Matti
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On 21/12/14 03:04, meino.cra...@gmx.de wrote: Matti Nykyri matti.nyk...@iki.fi [14-12-20 19:48]: On Dec 20, 2014, at 17:56, meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-20 02:47]: meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-19 17:08]: Mick wrote: Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. I don't recall ever running fix_libtool_files.sh after switching gcc versions. Usually when I see a gcc upgrade, I emerge it, switch to it and the usual profile thing, run emerge -e world JUST to be safe, then unmerge the old gcc. That's all I usually do here. I have skipped the emerge -e world a time or two. Am I just lucky, not likely as some may know, or does emerge -e world catch it or what? Now I'm curious. Dale :-) :-) Hi Dale, I started compiling the new gcc this morning about ~7:00 AM...just a few minutes ago stage3 finishes. Now ... before doing anything else... I am makeing a backup of all that, so...if anything fails...I am able to reinstall the status quo. I will keep you informed, what happens to my little embedded system... Best Meino That's the thing about slow systems, you want to do it right the first time because it takes to much time to repeat something. Heck, I have a 4 core AMD CPU with 16GBs of ram here and I still would rather do it right the first time. If you have something slow that takes days to do something, you really want plan A to work. I'm also wondering if there have been changes to emerge that could make a difference. I run the latest unstable non * version. I sorta like having all the new improvements. I'm just not sure if that affects the issue here is all. Dale :-) :-) Hi, after a few more non-booting-systems and backup-reinstalls I think I know whats the reason is...but by I dont know how to get out of it: The system becomes inaccessible if I do an env-update and reboot. Reason for that are binaries, in which the path to the old gcc is hardcoded. With the sdcard mounted I checked that with my PC: I did a grep -r '\/usr\/lib\/gcc\/armv7a-hardfloat-linux-gnueabi\/4.7.3' on ALL files of the sdcard and found thousands of hardcoded links to the old gcc inside binaries... The new gcc installed but not doing env-update implies that any further compilation will link to the old gcc. Doing env-update implies a system which will not survive the next reboot. What now? If i understand your situation correctly, do: gcc-config to set the new version env-update logout login emerge --deep --update world emerge --depclean revdep-rebuild This will take a long time but will get your system working again. If you don't wan't to do that you can of course tweak the libraries with binary tools. That is easy if you know what you are doing. To prevent this in the future always before world update, update gcc and glibc first if tere is a new version available. Gcc-config is crusial after you have installed a bew version of gcc. -- -Matti Hi Matti, not exactly... The sequence you show looks like this in my case: gcc-config to set the new version env-update reboot logina attempt: impossible...system does not respond anymore The reason is, that env-update updates to the new compiler, while some [CENSORED] system tools/application are hardcoded to use the old compiler libraries... If I do a env-update --no-ldconfig then I am able to reboot successfully...but compilation will be done against the old compiler a fear... I am installing the backup the fourth time today and I am curious, when the first bad sectors of my sdcard will hit me... Best regards, Meino Nowhere do you say you run the fix utility - even if its run automatically you will need to run it EACH TIME you run gcc-config. Sometimes you wont get a hit, but often it will. You will also need to run it at least ONCE against EVERY version of gcc ever installed in that OS (as it only looks for the old version number you give it.) gcc-config sets the symlinks to point to the version of gcc you want to use. The fix utility changes the library internal gcc libraries to point to the proper gcc lib. There have been non-gcc cases where you have to trawl the lib directories replacing the errant entries where neccessary (libpng anyone :) BillK
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 Dec 2014 07:22:30 meino.cra...@gmx.de wrote: Bill Kenworthy bi...@iinet.net.au [14-12-19 08:00]: On 19/12/14 13:39, meino.cra...@gmx.de wrote: Hi, (this happens on a embedded system) I ran into a problem I think... As adviced I run emerge --depclean -v -p after a greater update to world. (by the way: Updateing the world is generally to a bad idea...;) Beside other things, gcc-4.7.3 was slated for removal. As gcc-4.8.3 was already installed and gcc-config shows that it is active, I started the above command without -p And it screws up the whole thing badly: There were many, many applications (the shell for example...) which were directly linked to /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1 and/or /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libstdc++.so.6 After clearing the sdcard and reinstalling the backup I started to emerge all affected ebuilds by hand...only to find, that they were again linked against the old libs. I checked again with gcc-config and found: beagleboneblack:/rootgcc-config -L /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3 beagleboneblack:/rootgcc-config -c armv7a-hardfloat-linux-gnueabi-4.8.3 beagleboneblack:/rootgcc-config -E export PATH=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.8.3:/lib/rc/bin:/b in:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bi n:/usr/local/sbin:/bin/:/opt/bin:/usr/armv7a-hardfloat-linux-gnueabi/gc c-bin/4.8.3:/usr/games/bin:/root/bin export GCC_SPECS= What is going on here? Why still the old compiler and its libraries are used? How can I convince Gentoo to finally switch ti gcc-4.8.3? What do you think? Best regards, Meino Did you run fix_libtool_files.sh? - you have to do it manually after switching gcc to a bew version. BillK Hi Bill, Thanks for your help and hint! :) In the meanwhile I found a trace of a bad install of version 4.8.3: /etc/env.d/*gcc* was not updated. Currently I am reinstalling the whole gcc-4.8.3. - suit and after that I will call fix_libtool_files.sh. Hope it will fix it! Best regards, Meino This caught me out once too. I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
Mick michaelkintz...@gmail.com [14-12-19 12:20]: On Friday 19 Dec 2014 07:22:30 meino.cra...@gmx.de wrote: Bill Kenworthy bi...@iinet.net.au [14-12-19 08:00]: On 19/12/14 13:39, meino.cra...@gmx.de wrote: Hi, (this happens on a embedded system) I ran into a problem I think... As adviced I run emerge --depclean -v -p after a greater update to world. (by the way: Updateing the world is generally to a bad idea...;) Beside other things, gcc-4.7.3 was slated for removal. As gcc-4.8.3 was already installed and gcc-config shows that it is active, I started the above command without -p And it screws up the whole thing badly: There were many, many applications (the shell for example...) which were directly linked to /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1 and/or /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libstdc++.so.6 After clearing the sdcard and reinstalling the backup I started to emerge all affected ebuilds by hand...only to find, that they were again linked against the old libs. I checked again with gcc-config and found: beagleboneblack:/rootgcc-config -L /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3 beagleboneblack:/rootgcc-config -c armv7a-hardfloat-linux-gnueabi-4.8.3 beagleboneblack:/rootgcc-config -E export PATH=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.8.3:/lib/rc/bin:/b in:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bi n:/usr/local/sbin:/bin/:/opt/bin:/usr/armv7a-hardfloat-linux-gnueabi/gc c-bin/4.8.3:/usr/games/bin:/root/bin export GCC_SPECS= What is going on here? Why still the old compiler and its libraries are used? How can I convince Gentoo to finally switch ti gcc-4.8.3? What do you think? Best regards, Meino Did you run fix_libtool_files.sh? - you have to do it manually after switching gcc to a bew version. BillK Hi Bill, Thanks for your help and hint! :) In the meanwhile I found a trace of a bad install of version 4.8.3: /etc/env.d/*gcc* was not updated. Currently I am reinstalling the whole gcc-4.8.3. - suit and after that I will call fix_libtool_files.sh. Hope it will fix it! Best regards, Meino This caught me out once too. I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. -- Regards, Mick Hi Mick, if call fix_libtool_files.sh needs to be run AFTER the installation of gcc AND after removeing the old...then I never get rid of the old one, cause there are still vital (system ) applications are build against libs of the old gcc and will fail, if the old one has been removed (or better: fail /while/ the old gcc is being removed). A cat bits into its own tail, it seems... So again: how can I get out of this circle of death and system corruption ? Best Meino
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 December 2014 11:18:34 Mick wrote: I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. I've found that emerge -c gcc runs fix_libtool_files.sh automatically. This has been true for quite a while now. -- Rgds Peter.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
Peter Humphrey pe...@prh.myzen.co.uk [14-12-19 16:12]: On Friday 19 December 2014 11:18:34 Mick wrote: I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. I've found that emerge -c gcc runs fix_libtool_files.sh automatically. This has been true for quite a while now. -- Rgds Peter. Hi Peter, that implies that running fix_libtool_files.sh right after installing gcc is ok before removing the old gcc. This is the opposite from previous mail. By the way: I could'n find optino -c for emerge in the manpages... Best Meino
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 Dec 2014 15:09:37 Peter Humphrey wrote: On Friday 19 December 2014 11:18:34 Mick wrote: I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. I've found that emerge -c gcc runs fix_libtool_files.sh automatically. This has been true for quite a while now. Peter, I thought that this was the case, but recently I had to run fix_libtool_files.sh manually. I removed the old gcc thinking all is good, after I had switched to the new gcc with gcc-config, but I ended up with errors. I had to reinstall the old gcc, run fix_libtool_files.sh and then unmerge it again before the errors went away. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 December 2014 16:23:58 meino.cra...@gmx.de wrote: Peter Humphrey pe...@prh.myzen.co.uk [14-12-19 16:12]: On Friday 19 December 2014 11:18:34 Mick wrote: I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. I've found that emerge -c gcc runs fix_libtool_files.sh automatically. This has been true for quite a while now. that implies that running fix_libtool_files.sh right after installing gcc is ok before removing the old gcc. This is the opposite from previous mail. I don't know about that, but it's consistent with what you quote from Mick, above, and it works for me - though I see Mick has had a problem recently. By the way: I could'n find optino -c for emerge in the manpages... It means depclean. -- Rgds Peter.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 Dec 2014 15:23:58 meino.cra...@gmx.de wrote: Peter Humphrey pe...@prh.myzen.co.uk [14-12-19 16:12]: On Friday 19 December 2014 11:18:34 Mick wrote: I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. I've found that emerge -c gcc runs fix_libtool_files.sh automatically. This has been true for quite a while now. Hi Peter, that implies that running fix_libtool_files.sh right after installing gcc is ok before removing the old gcc. This is the opposite from previous mail. By the way: I could'n find optino -c for emerge in the manpages... Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
Mick michaelkintz...@gmail.com [14-12-19 16:52]: On Friday 19 Dec 2014 15:23:58 meino.cra...@gmx.de wrote: Peter Humphrey pe...@prh.myzen.co.uk [14-12-19 16:12]: On Friday 19 December 2014 11:18:34 Mick wrote: I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. I've found that emerge -c gcc runs fix_libtool_files.sh automatically. This has been true for quite a while now. Hi Peter, that implies that running fix_libtool_files.sh right after installing gcc is ok before removing the old gcc. This is the opposite from previous mail. By the way: I could'n find optino -c for emerge in the manpages... Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. -- Regards, Mick Hi Mick, thanks for makeing things clear! :) One man - one word - one gcc version! :)) THX! Best Meino
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
Mick wrote: Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. I don't recall ever running fix_libtool_files.sh after switching gcc versions. Usually when I see a gcc upgrade, I emerge it, switch to it and the usual profile thing, run emerge -e world JUST to be safe, then unmerge the old gcc. That's all I usually do here. I have skipped the emerge -e world a time or two. Am I just lucky, not likely as some may know, or does emerge -e world catch it or what? Now I'm curious. Dale :-) :-)
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 Dec 2014 15:53:53 meino.cra...@gmx.de wrote: Mick michaelkintz...@gmail.com [14-12-19 16:52]: On Friday 19 Dec 2014 15:23:58 meino.cra...@gmx.de wrote: Peter Humphrey pe...@prh.myzen.co.uk [14-12-19 16:12]: On Friday 19 December 2014 11:18:34 Mick wrote: I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. I've found that emerge -c gcc runs fix_libtool_files.sh automatically. This has been true for quite a while now. Hi Peter, that implies that running fix_libtool_files.sh right after installing gcc is ok before removing the old gcc. This is the opposite from previous mail. By the way: I could'n find optino -c for emerge in the manpages... Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. Hi Mick, thanks for makeing things clear! :) One man - one word - one gcc version! :)) THX! You're welcome. Peter's right the '--depclean --verbose' options will warn you if something you have already installed depends on the old gcc version. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
Dale rdalek1...@gmail.com [14-12-19 17:08]: Mick wrote: Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. I don't recall ever running fix_libtool_files.sh after switching gcc versions. Usually when I see a gcc upgrade, I emerge it, switch to it and the usual profile thing, run emerge -e world JUST to be safe, then unmerge the old gcc. That's all I usually do here. I have skipped the emerge -e world a time or two. Am I just lucky, not likely as some may know, or does emerge -e world catch it or what? Now I'm curious. Dale :-) :-) Hi Dale, I started compiling the new gcc this morning about ~7:00 AM...just a few minutes ago stage3 finishes. Now ... before doing anything else... I am makeing a backup of all that, so...if anything fails...I am able to reinstall the status quo. I will keep you informed, what happens to my little embedded system... Best Meino
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 Dec 2014 16:06:46 Dale wrote: Mick wrote: Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. I don't recall ever running fix_libtool_files.sh after switching gcc versions. Usually when I see a gcc upgrade, I emerge it, switch to it and the usual profile thing, run emerge -e world JUST to be safe, then unmerge the old gcc. That's all I usually do here. I have skipped the emerge -e world a time or two. Am I just lucky, not likely as some may know, or does emerge -e world catch it or what? Now I'm curious. I don't recall having run emerge -e world following a gcc update since about 2005, on at least half a dozen gentoo installations. This is because I do not have a need to have ALL my systems and their applications rebuilt with the very latest gcc version. Bear in mind that some packages may not even use gcc, so you're remerging them unnecessarily. Since electricity is not free in my household, I only emerge what I need. Of course, YMMV. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
Mick michaelkintz...@gmail.com [14-12-19 17:12]: On Friday 19 Dec 2014 15:53:53 meino.cra...@gmx.de wrote: Mick michaelkintz...@gmail.com [14-12-19 16:52]: On Friday 19 Dec 2014 15:23:58 meino.cra...@gmx.de wrote: Peter Humphrey pe...@prh.myzen.co.uk [14-12-19 16:12]: On Friday 19 December 2014 11:18:34 Mick wrote: I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. I've found that emerge -c gcc runs fix_libtool_files.sh automatically. This has been true for quite a while now. Hi Peter, that implies that running fix_libtool_files.sh right after installing gcc is ok before removing the old gcc. This is the opposite from previous mail. By the way: I could'n find optino -c for emerge in the manpages... Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. Hi Mick, thanks for makeing things clear! :) One man - one word - one gcc version! :)) THX! You're welcome. Peter's right the '--depclean --verbose' options will warn you if something you have already installed depends on the old gcc version. -- Regards, Mick Hi, backup done! now... gcc-4.8.3 is installed, gcc-config points to the new compiler, the environment is updated (I logged out and in again) and I checked /etc/env.d/04gcc-armv7a-hardfloat-linux-gnueabi for using the new compiler. So everything is fine...except... If I would remove the old compiler now, my system would again be broken. I run the following little loop (zsh) (.) means: only files): for i in /sbin/*(.) /bin/*(.) /usr/sbin/*(.) /usr/bin/*(.) do ldd $i | grep -q -s '/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1' if [[ $? == 0 ]] ; then echo $i /tmp/gccfiles6.txt ; fi done I did find 1033 executables still linked against /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1 and may be there are more being linked against other libs of the old compiler. Should I rebuild Gentoo? This would take a very very long time on this little system... How to proceed now? Best Meino
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [14-12-19 17:08]: Mick wrote: Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. I don't recall ever running fix_libtool_files.sh after switching gcc versions. Usually when I see a gcc upgrade, I emerge it, switch to it and the usual profile thing, run emerge -e world JUST to be safe, then unmerge the old gcc. That's all I usually do here. I have skipped the emerge -e world a time or two. Am I just lucky, not likely as some may know, or does emerge -e world catch it or what? Now I'm curious. Dale :-) :-) Hi Dale, I started compiling the new gcc this morning about ~7:00 AM...just a few minutes ago stage3 finishes. Now ... before doing anything else... I am makeing a backup of all that, so...if anything fails...I am able to reinstall the status quo. I will keep you informed, what happens to my little embedded system... Best Meino That's the thing about slow systems, you want to do it right the first time because it takes to much time to repeat something. Heck, I have a 4 core AMD CPU with 16GBs of ram here and I still would rather do it right the first time. If you have something slow that takes days to do something, you really want plan A to work. I'm also wondering if there have been changes to emerge that could make a difference. I run the latest unstable non * version. I sorta like having all the new improvements. I'm just not sure if that affects the issue here is all. Dale :-) :-)
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On Friday 19 Dec 2014 18:23:36 meino.cra...@gmx.de wrote: Mick michaelkintz...@gmail.com [14-12-19 17:12]: On Friday 19 Dec 2014 15:53:53 meino.cra...@gmx.de wrote: Mick michaelkintz...@gmail.com [14-12-19 16:52]: On Friday 19 Dec 2014 15:23:58 meino.cra...@gmx.de wrote: Peter Humphrey pe...@prh.myzen.co.uk [14-12-19 16:12]: On Friday 19 December 2014 11:18:34 Mick wrote: I run fix_libtool_files.sh after a new gcc is installed, BEFORE I remove the old version. I made a bit of a habit of this, but I don't know if modern ebuilds of gcc actually run the same script post install. I've found that emerge -c gcc runs fix_libtool_files.sh automatically. This has been true for quite a while now. Hi Peter, that implies that running fix_libtool_files.sh right after installing gcc is ok before removing the old gcc. This is the opposite from previous mail. By the way: I could'n find optino -c for emerge in the manpages... Meino, to avoid misunderstandings: 1. Emerge the new gcc package. 2. Use gcc-config to change to the new gcc version. 3. Run 'env-update source /etc/profile'. 4. Run fix_libtool_files.sh, although I would think that this is redundant these days. 5. Unmerge the old gcc version. Hi Mick, thanks for makeing things clear! :) One man - one word - one gcc version! :)) THX! You're welcome. Peter's right the '--depclean --verbose' options will warn you if something you have already installed depends on the old gcc version. Hi, backup done! now... gcc-4.8.3 is installed, gcc-config points to the new compiler, the environment is updated (I logged out and in again) and I checked /etc/env.d/04gcc-armv7a-hardfloat-linux-gnueabi for using the new compiler. So everything is fine...except... If I would remove the old compiler now, my system would again be broken. I run the following little loop (zsh) (.) means: only files): for i in /sbin/*(.) /bin/*(.) /usr/sbin/*(.) /usr/bin/*(.) do ldd $i | grep -q -s '/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1' if [[ $? == 0 ]] ; then echo $i /tmp/gccfiles6.txt ; fi done I did find 1033 executables still linked against /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1 and may be there are more being linked against other libs of the old compiler. Should I rebuild Gentoo? This would take a very very long time on this little system... How to proceed now? Well, it would be unwise to uninstall the old version with all these links in your filesystem. What do you get if you run manually 'fix_libtool_files.sh'? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Getting rid of gcc-4.7.3...how?
Hi, (this happens on a embedded system) I ran into a problem I think... As adviced I run emerge --depclean -v -p after a greater update to world. (by the way: Updateing the world is generally to a bad idea...;) Beside other things, gcc-4.7.3 was slated for removal. As gcc-4.8.3 was already installed and gcc-config shows that it is active, I started the above command without -p And it screws up the whole thing badly: There were many, many applications (the shell for example...) which were directly linked to /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1 and/or /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libstdc++.so.6 After clearing the sdcard and reinstalling the backup I started to emerge all affected ebuilds by hand...only to find, that they were again linked against the old libs. I checked again with gcc-config and found: beagleboneblack:/rootgcc-config -L /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3 beagleboneblack:/rootgcc-config -c armv7a-hardfloat-linux-gnueabi-4.8.3 beagleboneblack:/rootgcc-config -E export PATH=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.8.3:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/bin/:/opt/bin:/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.8.3:/usr/games/bin:/root/bin export GCC_SPECS= What is going on here? Why still the old compiler and its libraries are used? How can I convince Gentoo to finally switch ti gcc-4.8.3? What do you think? Best regards, Meino
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
On 19/12/14 13:39, meino.cra...@gmx.de wrote: Hi, (this happens on a embedded system) I ran into a problem I think... As adviced I run emerge --depclean -v -p after a greater update to world. (by the way: Updateing the world is generally to a bad idea...;) Beside other things, gcc-4.7.3 was slated for removal. As gcc-4.8.3 was already installed and gcc-config shows that it is active, I started the above command without -p And it screws up the whole thing badly: There were many, many applications (the shell for example...) which were directly linked to /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1 and/or /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libstdc++.so.6 After clearing the sdcard and reinstalling the backup I started to emerge all affected ebuilds by hand...only to find, that they were again linked against the old libs. I checked again with gcc-config and found: beagleboneblack:/rootgcc-config -L /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3 beagleboneblack:/rootgcc-config -c armv7a-hardfloat-linux-gnueabi-4.8.3 beagleboneblack:/rootgcc-config -E export PATH=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.8.3:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/bin/:/opt/bin:/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.8.3:/usr/games/bin:/root/bin export GCC_SPECS= What is going on here? Why still the old compiler and its libraries are used? How can I convince Gentoo to finally switch ti gcc-4.8.3? What do you think? Best regards, Meino Did you run fix_libtool_files.sh? - you have to do it manually after switching gcc to a bew version. BillK
Re: [gentoo-user] Getting rid of gcc-4.7.3...how?
Bill Kenworthy bi...@iinet.net.au [14-12-19 08:00]: On 19/12/14 13:39, meino.cra...@gmx.de wrote: Hi, (this happens on a embedded system) I ran into a problem I think... As adviced I run emerge --depclean -v -p after a greater update to world. (by the way: Updateing the world is generally to a bad idea...;) Beside other things, gcc-4.7.3 was slated for removal. As gcc-4.8.3 was already installed and gcc-config shows that it is active, I started the above command without -p And it screws up the whole thing badly: There were many, many applications (the shell for example...) which were directly linked to /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1 and/or /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libstdc++.so.6 After clearing the sdcard and reinstalling the backup I started to emerge all affected ebuilds by hand...only to find, that they were again linked against the old libs. I checked again with gcc-config and found: beagleboneblack:/rootgcc-config -L /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3 beagleboneblack:/rootgcc-config -c armv7a-hardfloat-linux-gnueabi-4.8.3 beagleboneblack:/rootgcc-config -E export PATH=/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.8.3:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/bin/:/opt/bin:/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.8.3:/usr/games/bin:/root/bin export GCC_SPECS= What is going on here? Why still the old compiler and its libraries are used? How can I convince Gentoo to finally switch ti gcc-4.8.3? What do you think? Best regards, Meino Did you run fix_libtool_files.sh? - you have to do it manually after switching gcc to a bew version. BillK Hi Bill, Thanks for your help and hint! :) In the meanwhile I found a trace of a bad install of version 4.8.3: /etc/env.d/*gcc* was not updated. Currently I am reinstalling the whole gcc-4.8.3. - suit and after that I will call fix_libtool_files.sh. Hope it will fix it! Best regards, Meino
