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:/root>gcc-config -L > > > > /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3 > > > > beagleboneblack:/root>gcc-config -c > > > > armv7a-hardfloat-linux-gnueabi-4.8.3 > > > > beagleboneblack:/root>gcc-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
