18384 – update from glibc-2.3.1-r2 to glibc-2.3.1-r4 fails wit´h distcc & ccache

Bug 18384 - update from glibc-2.3.1-r2 to glibc-2.3.1-r4 fails wit´h distcc & ccache

Summary: update from glibc-2.3.1-r2 to glibc-2.3.1-r4 fails wit´h distcc & ccache

Status:	RESOLVED DUPLICATE of bug 8607

Alias:	None

Product:	Gentoo Linux
Classification:	Unclassified
Component:	New packages (show other bugs)
Hardware:	x86 Linux

Importance:	High major (vote)
Assignee:	Gentoo Linux bug wranglers

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2003-03-28 13:41 UTC by Sam Wouters
Modified:	2005-07-17 13:06 UTC (History)
CC List:	1 user (show)

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Sam Wouters 2003-03-28 13:41:02 UTC

When I try to emerge glibc-2.3.1-r4, on both of my systems (athlon and pentium4), the 
install process hangs at the following line: 
mv -f /var/tmp/portage/glibc-2.3.1-r4/work/glibc-2.3.1/buildhere/stdlib/stamp.oST 
/var/tmp/portage/glibc-2.3.1-r4/work/glibc-2.3.1/buildhere/stdlib/stamp.oS 
 
Disabling the distcc and ccache features lets the emerge process finish succesfully. 

Reproducible: Always
Steps to Reproduce:
1. add distcc and ccache to the portage features 
2. emerge glibc 
3. 
Actual Results:  
the install process hangs at the line: 
mv -f /var/tmp/portage/glibc-2.3.1-r4/work/glibc-2.3.1/buildhere/stdlib/stamp.oST 
/var/tmp/portage/glibc-2.3.1-r4/work/glibc-2.3.1/buildhere/stdlib/stamp.oS 
 
cpu usage drops to zero 

Expected Results:  
upgrade glibc 

Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r2) 
================================================================= 
System uname: 2.4.20-gentoo-r1 i686 Intel(R) Pentium(R) 4 CPU 1500MHz 
GENTOO_MIRRORS=" http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/" 
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config 
/usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/kde/3/share/config 
/usr/share/config" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" 
PORTDIR="/usr/portage" 
DISTDIR="/usr/portage/distfiles" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/var/tmp" 
PORTDIR_OVERLAY="/usr/local/portage" 
USE="x86 oss 3dnow apm avi crypt cups encode gif jpeg libg++ mikmod mmx mpeg 
ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gtkhtml gdbm berkdb 
slang readline arts aalib nas bonobo svga ggi tcltk java guile X sdl gpm tcpd pam 
libwww ssl python esd imlib oggvorbis qt kde motif opengl scanner acpi cdr dga 
directfb doc dvd fbcon -gnome gphoto2 -gtk matrox mozilla mysql perl pic postgres 
samba sse tetex tiff usb wmf xfs" 
COMPILER="gcc3" 
CHOST="i686-pc-linux-gnu" 
CFLAGS="-march=pentium3 -O3 -pipe" 
CXXFLAGS="-march=pentium3 -O3 -pipe" 
ACCEPT_KEYWORDS="x86" 
MAKEOPTS="-j3" 
AUTOCLEAN="yes" 
SYNC="rsync://rsync.gentoo.org/gentoo-portage" 
FEATURES="sandbox distcc ccache"

Comment 1 Sam Wouters 2003-06-29 14:01:58 UTC

Hi, 
 
I forgot to update the bug, but the problem wasn't afterall with the glibc ebuild. I 
experienced the problem later with a few other ebuilds and it turned out it was metalog 
that was hanging. After aplying the metalog-patch from bug #8607 the problem was 
solved. 
 
Sam

Comment 2 Martin Holzer (RETIRED) gentoo-dev

2003-06-29 14:03:51 UTC


*** This bug has been marked as a duplicate of 8607 ***