Bugzilla Bug 198949

When I try to compile splashutils, it fails with the following message:
  LD      objs/fbsplashd.static
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../lib64/libpthread.a(pthread_cond_timedwait.o):
In function `pthread_cond_timedwait':
(.text+0xa7): undefined reference to `__vdso_clock_gettime'
collect2: ld returned 1 exit status
make: *** [objs/fbsplashd.static] Error 1

Reproducible: Always




When I was using baselayout < 2 and glibc2.6, splashutils compiled fine; but
then I upgraded baselayout2 and glibc2.7 and it no longer compiles. After some
searches, it appears to be a glibc2.7 AMD64 problem.

My emerge --info:
Portage 2.1.3.19 (default-linux/amd64/2007.0, gcc-4.2.2, glibc-2.7-r0,
2.6.23-tuxonice x86_64)
=================================================================
System uname: 2.6.23-tuxonice x86_64 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz
Timestamp of tree: Mon, 12 Nov 2007 14:30:09 +0000
app-shells/bash:     3.2_p17-r1
dev-lang/python:     2.4.4-r6, 2.5.1-r3
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 2.0.0_rc6
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.61-r1
sys-devel/automake:  1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.23-r1
ACCEPT_KEYWORDS="amd64 ~amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/gentoo-release
/etc/revdep-rebuild /etc/splash /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-march=nocona -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict
unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl amd64 berkdb bitmap-fonts cli cracklib crypt cups dri fortran gdbm gpm
iconv isdnlog midi mmx mudflap ncurses nls nptl nptlonly openmp pam pcre perl
pppd python readline reflection session spl sse sse2 ssl tcpd truetype-fonts
type1-fonts unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem
bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel
intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix
dummy fbdev glint i128 i810 mach64 mga neomagic nv r128 radeon rendition s3
s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via
vmware voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

I also have this problem. I have ~amd64 too and other parameters are very
similar.
Problem appears only when I try to emerge splashutils with "mng" USE flag.

Confirmed. This seems to be a glibc-2.7 problem.

Same here. I also get the following message after unpack:

 * The kernel tree against which dev-libs/klibc was built was not patched
 * with a compatible version of fbcondecor. Splashutils will be compiled
 * without fbcondecor support (i.e. verbose mode will not work).

I don't know if this warning is related to the build failure, I'm using
gentoo-sources-2.6.23 and glibc-2.7 of course.

you may be SOL.  upstream glibc has stated that static linking is not supported
at all (and in fact, has other known issues where things break subtly at
runtime).

that said, before i look into the source code, why does splashutils need to be
statically linked in the first place ?

this is a simple reduced test case:
int main(){pthread_cond_timedwait(0,0,0);}

fbsplashd is linked with a number of graphics libraries (libpng, libmng, ...)
which are located in /usr/lib.  If the user has a separate /usr partition,
these libraries are unavailable at the time the fbsplash daemon is started and
thus a statically linked version has to be used.

ive asked upstream, but i cant promise things look good

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

Created an attachment (id=136911) [details]
A patch for glibc to fix the problem.

(In reply to comment #8)
> Created an attachment (id=136911) [edit] [details]
> A patch for glibc to fix the problem.
> 

Confirmed the patch worked. The problem was resolved on ~amd64 (with
gcc-4.3-svn).

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

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

Ok, so putting the proposed patch into
"${PORTDIR_OVERLAY}"/dev-libs/glibc/files/2.7/glibc-2.7-pthread_cond_timewait.patch

and applying the following diff:
# diff /usr/portage/sys-libs/glibc/glibc-2.7.ebuild
/usr/local/portage/sys-libs/glibc/glibc-2.7.ebuild 
29c29
< IUSE="debug gd glibc-omitfp glibc-compat20 hardened multilib nls selinux
profile vanilla ${LT_VER:+glibc-compat20 nptl nptlonly}"
---
> IUSE="debug gd glibc-omitfp glibc-compat20 hardened mng-splash multilib nls selinux profile vanilla ${LT_VER:+glibc-compat20 nptl nptlonly}"
160a161,165
>       if use mng-splash ; then
>               cd "${S}"
>               einfo "Patching to get working mng-support in splashutils"
>               epatch "${FILESDIR}"/2.7/glibc-2.7-pthread_cond_timewait.patch
>       fi

makes the patch apply ok and glibc to emerge OK. But then all hell breaks
loose; whatever I try to emerge, it all ends up with random errors, mostly at
configure. They all seemed to have to do with a broken libsandbox...
Anyway, I suppose one should rebuild toolchain instead of just rebuilding
glibc, right?

I would be more than happy to help out getting mng-support in splashutils, but
I'm affraid I'm stuck here...
I'm on ~amd64, gcc-4.2.2 and glibc-1.7 (now unpatched)

Cheers! /Charlie

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

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

(In reply to comment #12)
> makes the patch apply ok and glibc to emerge OK. But then all hell breaks
> loose; whatever I try to emerge, it all ends up with random errors, mostly at
> configure. They all seemed to have to do with a broken libsandbox...
> Anyway, I suppose one should rebuild toolchain instead of just rebuilding
> glibc, right?

Charlie, could you please include some of these errors that you're seeing when
glibc is compiled with this patch?  Also, could you please provide your `emerge
--info`?

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

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

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

fixed in glibc-2.7-r1

http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.7/1065_all_glibc-x86_64-libpthread-no-vdso.patch?rev=1.1