Bug 16348 – emerge -u gcc to gcc 3.2.2 doesn't set 3.2.2 as default gcc, there get errors with emerge

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Lance Lassetter 2003-02-25 09:17:28 UTC]

Updated with emerge gcc, binutils to latest stable version in Portage, new gcc
wasn't set in the system, tried 'emerge rsync', got error "python2.2: error
while loading shared libraries: libstdc++.so.5: cannot open shared object file:
No such file or directory"

Had to manually set path to gcc 3.2.2 in /etc/ld.so.conf, reinstall gcc-config,
then set system compiler to gcc 3.2.2 with gcc-config to fix.

Seems containing gcc-config in the gcc ebuild to set gcc that is installed with
emerge would be an option.



Reproducible: Always
Steps to Reproduce:
1. emerge rsync, emerge -u gcc binutils
2. emerge rsync
3. on second emerge rsync, produced above error (python2.2: error while loading
shared libraries: libstdc++.so.5: cannot open shared object file: No such file
or directory)

Actual Results:  
Portage becomes broken until manually set gcc with gcc-config or temporary fix
of adding gcc 3.2.2 to /etc/ld.so.conf.

Expected Results:  
Update and install of latest stable gcc in Portage should set system compiler to
3.2.2 with no problems.

[Comment 1 Martin Schlemmer (RETIRED) 2003-02-25 16:32:27 UTC]

The ebuild does run gcc-config.  I cannot recreate this.  I have even done
full bootstraps with gcc-3.2.1 and then updated gcc, and it still worked
fine for me (done all this after a similar bug).

A note though ... all this does get run in pkg_postinst(), thus if portage
borks with the relocation error before it gets run, this will be the outcome.
We will this then rather have to figure out why a few people do the the
relocation errors .....

[Comment 2 Martin Schlemmer (RETIRED) 2003-02-26 02:22:52 UTC]

Nick, can this be due to portage removing gcc-3.2.1 before it runs env-update ?

[Comment 3 Mark Rickard 2003-02-26 10:09:15 UTC]

This problem (cannot open libstdc++.so.5) occurred for me as well after 
updating from gcc 3.2.1 to gcc 3.2.2.  After a searching through the forums, I 
found a simple cause and solution to the problem.  My current, working 
/etc/env.d looks like this (05gcc and  
i686-pc-linux-gnu-3.2.2 are identical files): 
 
05gcc 
gcc/ 
	config 
	i686-pc-linux-gnu-3.2.2 
 
The original, non-functional /etc/env.d was missing 05gcc and only had the 
following files: 
 
gcc/ 
	config 
	i686-pc-linux-gnu-3.2.2 
 
  
Reproducible: Always 
Steps to reproduce: 
1. gcc -v 
	Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs 
	... 
2. rm /etc/env.d/05gcc 
3. env-update && source /etc/profile 
4. gcc -v 
	/usr/bin/gcc-config: line 116: return: can only `return' from a function or 
sourced script 
	Could not run/locate gcc! 
5. python 
	python: error while loading shared libraries: libstdc++.so.5: cannot open 
shared object file: No such file or directory 
 
Solution 
1. echo "/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2" >> /etc/ld.so.conf 
2. ldconfig 
3. gcc -v 
	Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs 
	... 
4. python 
	Python 2.2.2 (#1, Feb 24 2003, 14:53:26) 
	[GCC 3.2.2] on linux2 
	... 
 
I hope this helps resolve the issue.  I'm not sure why 
/etc/env.d/i686-pc-linux-gnu-3.2.2 is not being read. 
 
Mark 

[Comment 4 Martin Schlemmer (RETIRED) 2003-03-12 18:03:50 UTC]

I did some changes to the ebuild that should resolve this:

--------------------------
  09 Mar 2003; Martin Schlemmer <[e-mail]> gcc-3.2.2*.ebuild :
  Fix handling of fix_libtool_files.sh to be more $FILESDIR independant.
  We basically install it to /sbin now, and then call it from there.  Also
  export LD_LIBRARY_PATH with new gcc library path in it to prevent gcc-config
  from borking when run.  This will hopefully fix bugs #15288, #16632, #16797.

[Comment 5 Martin Schlemmer (RETIRED) 2003-04-08 18:18:42 UTC]

Should be fixed.  No further reports.