Bugzilla Bug 125887

After updating glibc to 2.4 and gcc to 4.1, while doing emerge -e system, wget
fails with this error:

x86_64-pc-linux-gnu-gcc -march=athlon64 -O2 -pipe  -o wget  cmpt.o connect.o
convert.o cookies.o ftp.o ftp-basic.o ftp-ls.o ftp-opie.o  hash.o host.o
html-parse.o html-url.o http.o http-ntlm.o init.o log.o main.o gen-md5.o
netrc.o progress.o ptimer.o recur.o res.o retr.o safe-ctype.o snprintf.o
openssl.o url.o utils.o version.o xmalloc.o  -lssl -lcrypto -Wl,-rpath
-Wl,/usr/lib64 -ldl
ptimer.o: In function `ptimer_reset':ptimer.c:(.text+0x2e): undefined reference
to `clock_gettime'
ptimer.o: In function `ptimer_new':ptimer.c:(.text+0xbe): undefined reference
to `clock_getres'
ptimer.o: In function `ptimer_measure':ptimer.c:(.text+0x1d2): undefined
reference to `clock_gettime'
collect2: ld returned 1 exit status

emerge --info
Portage 2.1_pre6 (default-linux/amd64/2006.0, gcc-3.4.5, glibc-2.4-r0,
2.6.15-ck5 x86_64)
=================================================================
System uname: 2.6.15-ck5 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.12.0_pre16
ccache version 2.4 [enabled]
dev-lang/python:     2.3.5-r2, 2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
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-r1, 2.16.91.0.3, 2.16.91.0.5, 2.16.91.0.6
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/lib64/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/terminfo
/etc/texmf/web2c /etc/env.d"
CXXFLAGS="-march=athlon64 -O2 -pipe -ffriend-injection"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS=""
FEATURES="autoconfig ccache confcache distlocks metadata-transfer nostrip
sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.osuosl.org/"
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/bmg-main /usr/local/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="amd64 X aac alsa avi bash-completion berkdb bitmap-fonts bzip2 cairo cdr
crypt cups dbus debug dri dvd dvdr eds emboss encode esd firefox flac
foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 hal imlib ipv6 java
jpeg kde ldap lzw lzw-tiff mad mono mozilla mp3 mpeg ncurses nls nptl nptlonly
ogg opengl pam pdflib perl pic png python qt quicktime readline ruby samba sdl
spell sqlite ssl tcpd theora tiff truetype truetype-fonts type1-fonts usb
vorbis xml2 xpm xv zlib elibc_glibc input_devices_keyboard input_devices_mouse
input_devices_evdev kernel_linux userland_GNU video_cards_vga video_cards_vesa
video_cards_nv"
Unset:  ASFLAGS, CTARGET, LDFLAGS, LINGUAS, MAKEOPTS

same error here.  syncing and remerging glibc made it go bye bye.

my bad.  this is a confcache bug.

to reproduce:

# rm /var/tmp/confcache/* && emerge =coreutils-5.94-r1 =wget-1.10.2

Works fine with the pre6-r5 for me.

(In reply to comment #4)
> Works fine with the pre6-r5 for me.

What are you talking about?  Did you comment on the wrong bug?

adding RESTRICT="confcache" to the coreutils ebuild should be enough to fix
this.

(In reply to comment #6)
> adding RESTRICT="confcache" to the coreutils ebuild should be enough to fix
> this.

Re-emerging coreutils with FEATURES="-confcache" didn't make any difference for
me, but emerging wget without confcache _did_ work.

i think that might have been because the config.cache value that causes the
breakage was still in your confcache.  using 'FEATURES="-confcache" emerge
coreutils' won't clear the cache or update it, so wget will still fail.  you're
right that 'FEATURES="-confcache" emerge wget' would work too because the cache
wouldn't be used, but then the bum entry from coreutils is still in the cache
and could cause problems for other packages down the road.

(In reply to comment #8)
> i think that might have been because the config.cache value that causes the
> breakage was still in your confcache.  using 'FEATURES="-confcache" emerge
> coreutils' won't clear the cache or update it, so wget will still fail.  

Ah, ok. So what is this bad config.cache value, and why is coreutils creating
it?

General goofyness i guess.

coreutils' configure is setting:
ac_cv_func_clock_gettime=${ac_cv_func_clock_gettime=yes}

wget's configure w/o using the cache comes up with:
ac_cv_func_clock_gettime=${ac_cv_func_clock_gettime=no}
ac_cv_lib_rt_clock_gettime=${ac_cv_lib_rt_clock_gettime=yes}

so wget using the coreutils cache thinks it can use clock_gettime without using
an external library.  in reality it can't, and needs to pass -lrt to have
access to that function.

i have no clue why coreutils can use clock_gettime natively while wget has to
get it from a library.  either way, putting a confcache restriction on the
coreutils ebuild will fix this.

*** Bug 124536 has been marked as a duplicate of this bug. ***

*** Bug 106087 has been marked as a duplicate of this bug. ***

*** Bug 125431 has been marked as a duplicate of this bug. ***

(In reply to comment #0)
Confirmed this happens for me with versions of gcc from 3.4.5 to 3.4.6 (stable
x86) as I originally reported in awhile ago in bug 124536. Confcache is the
culprit; see the above bug for my error message. Happens in all versions of
Portage 2.1, including the latest.

flameeyes...how 'bout a little love for this bug? :D

(In reply to comment #14)
As per ferringb's suggestion on another bug, deleting /var/tmp/confcache*,
enabling FEATURES="confcache" in make.conf, and adding RESTRICT="confcache" to
the wget ebuild, and emerging wget twice allows wget to be successfully built.

I also first emerged coreutils with confcache enabled just to see if that would
poison the subsequent wget compile (emerge coreutils wget), but wget built
successfully each time.

So that's sort of a good sign, though something still needs to be fixed
elsewhere before RESTRICT="confcache" can be taken out of the wget ebuild.

like i said before, the reason that works is because it just causes wget to not
use the poisoned cache.  however the problem is still there, just papered over.
 the proper solution is to add the restrict to the ebuild that does the
poisoning, ie. coreutils.  i've spoken to Brian and he confirmed it.  with
confcache bugs you have to find and fix the ebuild that introduces the invalid
cache entry, _not_ the ebuild that dies because of it.

FWIW, this also kills net-misc/ntp for the same reason and probably more that i
just haven't run into yet.

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