Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 114539 - emerge -P gcc performs incomplete purge when pruning GCC 3.4.4 off of a GCC 4.0.2 system
Summary: emerge -P gcc performs incomplete purge when pruning GCC 3.4.4 off of a GCC 4...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-05 08:30 UTC by Bob
Modified: 2005-12-07 00:10 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bob 2005-12-05 08:30:09 UTC
after installing GCC 4.0.2 on a system running GCC 3.4.4, and subsequently
updating the compiler choice to GCC 4.0.2 using gcc-config, an emerge -P of gcc
fails to completely remove gcc 3.4.4 from the system.  although the gcc 3.4.4
binary directories are removed, a number of remnants of gcc 3.4.4 remain in the
system environment.  namely:

1.  gcc-config -E shows that /usr/i686-pc-linux-gnu/gcc-bin/3.4.4 remains in the
export path, even though the binary directory has been removed.

2.  the file /etc/env.d/05gcc-i686-pc-linux-gnu remains present with the
following contents:

# cat /etc/env.d/05gcc-i686-pc-linux-gnu
PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.4.4"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.4.4"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/info"
LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/3.4.4"
GCC_SPECS=""

3.  the file /etc/env.d/gcc/config-i686-pc-linux-gnu remains present with the
following contents:

# cat /etc/env.d/gcc/config-i686-pc-linux-gnu
CURRENT=i686-pc-linux-gnu-3.4.4

4.  the file /etc/env.d/gcc/config isn't properly updated by gcc-config when the
user selects the new 4.0.2 compiler, so the user has to manually edit this file
to point to the new compiler.  this is actually a gcc-config bug, but i've
included it here for the sake of completeness.

Reproducible: Always
Steps to Reproduce:
1.emerge GCC 4.0.2
2.gcc-config to select new compiler
3. emerge -e system && emerge -e system
4.  emerge -P gcc

Actual Results:  
incomplete pruning of old compiler from system environment

Expected Results:  
complete pruning of old compiler from system environment
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-12-05 08:35:24 UTC
Portage never removes anything under CONFIG_PROTECT (man make.conf); file a
separate bug about gcc-config if there's not already one.
Comment 2 Bob 2005-12-05 10:25:31 UTC
thanks for the feedback.  in this case the files are not protected by config
protect, as the /etc/env.d folder is specified in the config protect mask:

(i know i should have provided this in the intitial post, but i didn't think
you'd be responding so quickly).

# emerge --info
Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r3,
2.6.11-gentoo-r6 i686)
=================================================================
System uname: 2.6.11-gentoo-r6 i686 Pentium III (Coppermine)
Gentoo Base System version 1.6.13
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS=" -O3 -march=pentium3 -mtune=pentium3 -pipe -fweb -frename-registers
-fforce-addr -fomit-frame-pointer -ftracer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS=" -O3 -march=pentium3 -mtune=pentium3 -pipe -fweb -frename-registers
-fforce-addr -fomit-frame-pointer -ftracer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distcc distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://grumpy.346net http://gentoo.netnitco.net
http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://grumpy.346net/gentoo-portage"
USE="x86 X acpi alsa apm arts audiofile avi berkdb bitmap-fonts bzip2 cddb crypt
cups curl eds emboss encode esd exif expat fam font-server foomaticdb fortran
gdbm gif glut gmp gphoto2 gpm gstreamer gtk gtk2 hal ide idn imlib ipv6 jpeg kde
lcms ldap libg++ libwww mad mikmod mmx mng motif mp3 mpeg nas ncurses nls nptl
oav ogg oggvorbis opengl oss pam pcre pdf pdflib perl png posix pthreads python
qt quicktime readline samba scanner sdl snmp spell sse ssl svga tcpd tiff
truetype truetype-fonts type1-fonts udev usb userlocales vorbis xine xinerama
xml xml2 xmms xscreensaver xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY

is it normal that no attempt should be made by portage to remove these files
when config-protect is turned off / the files in the directory are
config-protect-masked?  it does not seem appropriate that the environment path
would include pointers to binary directories that no longer exist.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2005-12-05 10:52:02 UTC
(In reply to comment #2)
> is it normal that no attempt should be made by portage to remove these files
> when config-protect is turned off / the files in the directory are
> config-protect-masked?  it does not seem appropriate that the environment path
> would include pointers to binary directories that no longer exist.

/etc/env.d/05gcc is not owned by any ebuild, so portage won't and should not
unmerge it (but I don't have /etc/env.d/05gcc-i686-pc-linux-gnu, it's
/etc/env.d/05gcc actually); the rest seems a gcc-config issue.

I also don't have /etc/env.d/gcc/config-i686-pc-linux-gnu here, it's
/etc/env.d/gcc/i686-pc-linux-gnu-<gcc_version> actually. So, you have some
weird-named files there, I don't think they've been installed by gcc-3.4.4
ebuild, so again they cannot be unmerged then, even under CONFIG_PROTECT_MASK.
You can re-emerge gcc-3.4.4 to check yourself.
Comment 4 Bob 2005-12-07 00:10:41 UTC
(In reply to comment #3)

> /etc/env.d/05gcc is not owned by any ebuild, so portage won't and should not
> unmerge it (but I don't have /etc/env.d/05gcc-i686-pc-linux-gnu, it's
> /etc/env.d/05gcc actually); the rest seems a gcc-config issue.


regarding problem 2 in my original post:

yes, i have /etc/env.d/gcc, and i understand that /etc/env.d/05gcc isn't "owned"
by any ebuild.  the file /etc/env.d/05gcc-i686-pc-linux-gnu also exists, even
though you report that you don't have it.

what appears to be happening (on ALL of my GCC 3.4.4 and GCC 4.0.2 systems) is
that the file 05gcc-i686-pc-linux-gnu exists, and it ALWAYS points to the
previous version of the GCC compiler that has been pruned.

in the case of the GCC 4.0 based systems, here is the contents of the file:

# cat /etc/env.d/05gcc-i686-pc-linux-gnu
PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.4.4"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.4.4"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/info"
LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/3.4.4"
GCC_SPECS=""

in the case of the GCC 3.4.4 based systems, here is the contents of the file:

env.d # cat 05gcc-i686-pc-linux-gnu
PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3"
ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3"

i'm wondering if this file is created during the toolkit upgrade as a backup of
the previous version of 05gcc, and it fails to get pruned by emerge -P gcc.  it
appears to be left in perpetuity as a remnant of the previous compiler.



> I also don't have /etc/env.d/gcc/config-i686-pc-linux-gnu here, it's
> /etc/env.d/gcc/i686-pc-linux-gnu-<gcc_version> actually. So, you have some
> weird-named files there, I don't think they've been installed by gcc-3.4.4
> ebuild, so again they cannot be unmerged then, even under CONFIG_PROTECT_MASK.
> You can re-emerge gcc-3.4.4 to check yourself.

i think that they get installed by the "new" compiler.  it appears that GCC
3.4.4 installs outdated files referencing GCC 3.3.4, and GCC 4.0.2 installs
outdated files referencing GCC 3.4.4.  

its interesting.  on EVERY ONE of my GCC 4.x based systems, you'd find the
following:

# vdir /etc/env.d
total 32
-rw-r--r--  1 root root 218 Nov 27 20:47 00basic
-rw-r--r--  1 root root 160 Nov 27 18:09 05binutils
-rw-r--r--  1 root root 269 Nov 27 19:12 05gcc
-rw-r--r--  1 root root 269 Nov  6 08:30 05gcc-i686-pc-linux-gnu
-rw-r--r--  1 root root  34 Nov 27 20:34 05portage.envd
-rw-r--r--  1 root root  36 Nov 27 18:04 50ncurses
-rw-r--r--  1 root root  10 Nov 27 20:56 70less
-rw-r--r--  1 root root  32 Nov 27 19:21 99libstdc++
drwxr-xr-x  2 root root 128 Nov 27 18:09 binutils
drwxr-xr-x  2 root root 152 Nov 27 19:12 gcc

# cat /etc/env.d/05gcc-i686-pc-linux-gnu
PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.4.4"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.4.4"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/info"
LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/3.4.4"
GCC_SPECS=""


# vdir /etc/env.d/gcc
total 12
-rw-r--r--  1 root root  32 Nov 27 19:12 config
-rw-r--r--  1 root root  32 Nov  6 08:30 config-i686-pc-linux-gnu
-rw-r--r--  1 root root 292 Nov 27 19:12 i686-pc-linux-gnu-4.0.2

# cat /etc/env.d/gcc/config-i686-pc-linux-gnu
CURRENT=i686-pc-linux-gnu-3.4.4


and on every one of my GCC 3.4.4 based systems, you'd find this:

gentoo env.d # vdir /etc/env.d
total 100
-rw-r--r--  1 root root 218 Oct 19 02:24 00basic
-rw-r--r--  1 root root  18 Dec  6 06:17 01hostname
-rw-r--r--  1 root root 139 Jun 28 09:07 02distcc
-rw-r--r--  1 root root  64 Oct  2 03:31 03opengl
-rw-r--r--  1 root root 160 Nov 30 01:05 05binutils
-rw-r--r--  1 root root 269 Nov 30 01:07 05gcc
-rw-r--r--  1 root root  92 Jun  4  2005 05gcc-
-rw-r--r--  1 root root  88 Apr  3  2005 05gcc-i686-pc-linux-gnu
-rw-r--r--  1 root root  34 Oct 19 02:11 05portage.envd
-rw-r--r--  1 root root  32 Oct 15 06:15 10MozillaFirefox
-rw-r--r--  1 root root  79 Oct  2 03:30 10xorg
-rw-r--r--  1 root root  28 Jun 28 00:06 30sane
-rw-r--r--  1 root root 109 Oct  1 20:00 45qt3
-rw-r--r--  1 root root 172 Oct 12 18:40 46kdepaths-3.4
-rw-r--r--  1 root root 172 Jun 27 10:01 47kdepaths-3.3.1
-rw-r--r--  1 root root  33 Oct 13 05:48 50gconf
-rw-r--r--  1 root root  21 Oct  1 23:51 50glib2
-rw-r--r--  1 root root  14 Nov 18 11:32 50gtk2
-rw-r--r--  1 root root  36 Oct 18 20:42 50ncurses
-rw-r--r--  1 root root  16 Oct  1 20:00 50qtdir3
-rw-r--r--  1 root root  41 Oct 13 05:55 60gstreamer-0.8
-rw-r--r--  1 root root  23 Dec  4 02:00 70less
-rw-r--r--  1 root root  66 Oct  2 00:31 99kde-env
-rw-r--r--  1 root root  32 Oct 18 22:37 99libstdc++
-rw-r--r--  1 root root  34 Nov  2 07:27 99splash
drwxr-xr-x  2 root root 128 Nov 30 01:05 binutils
drwxr-xr-x  2 root root 392 Oct 18 22:17 gcc


gentoo env.d # cat /etc/env.d/05gcc-i686-pc-linux-gnu
PATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3"
ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/3.3"

gentoo env.d # vdir /etc/env.d/gcc
total 32
-rw-r--r--  1 root root  32 Nov 30 01:07 config
-rw-r--r--  1 root root  32 Jun  4  2005 config-
-rw-r--r--  1 root root  32 Apr  3  2005 config-i686-pc-linux-gnu
-rw-r--r--  1 root root 292 Oct 18 22:17 i686-pc-linux-gnu-3.4.4
-rw-r--r--  1 root root 356 Oct 18 22:17 i686-pc-linux-gnu-3.4.4-hardened
-rw-r--r--  1 root root 361 Oct 18 22:17 i686-pc-linux-gnu-3.4.4-hardenednopie
-rw-r--r--  1 root root 364 Oct 18 22:17 i686-pc-linux-gnu-3.4.4-hardenednopiessp
-rw-r--r--  1 root root 361 Oct 18 22:17 i686-pc-linux-gnu-3.4.4-hardenednossp

gentoo env.d # cat /etc/env.d/gcc/config-i686-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-3.3.4
  

the common denominator is that the files point to the extinct versions of GCC
that have already been pruned from the system.  it makes no sense that these
files are being left behind, and its not a fluke, as i can replicate this on
more than 10 systems.