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 attachment 136911 [details, diff] A patch for glibc to fix the problem.
(In reply to comment #8) > Created an attachment (id=136911) [edit] > 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
