198949 2007-11-12 17:09 0000 sys-libs/glibc-2.7: static compilation while using pthread_cond_timedwait() fails 2007-12-10 01:32:53 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified AMD64 Linux RESOLVED FIXED http://sources.redhat.com/bugzilla/show_bug.cgi?id=5465 P2 normal --- 1 bilbotux@gmail.com toolchain@gentoo.org aaron@cs.tu-berlin.de charlie@gehlin.com claus.boehmer@gmx.de czarkoff@gmail.com daemon@kleczew.com dagger@gentoo.org davidepesa@gmail.com devurandom@gmx.net hongqn@gmail.com rufus-azrael@numericable.fr satana.hell@gmail.com spock@gentoo.org bilbotux@gmail.com 2007-11-12 17:09:41 0000 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 vlevykin@mail.ru 2007-11-13 08:21:47 0000 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. spock@gentoo.org 2007-11-13 16:15:42 0000 Confirmed. This seems to be a glibc-2.7 problem. davidepesa@gmail.com 2007-11-13 21:47:12 0000 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. vapier@gentoo.org 2007-11-14 04:24:53 0000 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);} spock@gentoo.org 2007-11-14 18:07:46 0000 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. vapier@gentoo.org 2007-11-14 20:16:26 0000 ive asked upstream, but i cant promise things look good jakub@gentoo.org 2007-11-21 09:39:46 0000 *** Bug 199866 has been marked as a duplicate of this bug. *** spock@gentoo.org 2007-11-24 19:31:59 0000 Created an attachment (id=136911) A patch for glibc to fix the problem. senuma.takahiko@gmail.com 2007-11-25 09:12:46 0000 (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). jakub@gentoo.org 2007-11-25 13:33:40 0000 *** Bug 200280 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-11-27 09:38:29 0000 *** Bug 200497 has been marked as a duplicate of this bug. *** charlie@gehlin.com 2007-11-27 12:39:14 0000 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 jakub@gentoo.org 2007-11-28 14:25:59 0000 *** Bug 200635 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-11-30 16:24:09 0000 *** Bug 200828 has been marked as a duplicate of this bug. *** spock@gentoo.org 2007-12-01 09:09:39 0000 (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`? jakub@gentoo.org 2007-12-01 11:07:39 0000 *** Bug 200910 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-12-08 08:44:34 0000 *** Bug 201645 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-12-09 21:41:23 0000 *** Bug 201806 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2007-12-10 01:14:36 0000 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 136911 2007-11-24 19:31 0000 A patch for glibc to fix the problem. glibc.patch text/plain ZGlmZiAtTmF1cnAgZ2xpYmMtMi43LW9yaWcvbnB0bC9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC94 ODZfNjQvcHRocmVhZF9jb25kX3RpbWVkd2FpdC5TIGdsaWJjLTIuNy9ucHRsL3N5c2RlcHMvdW5p eC9zeXN2L2xpbnV4L3g4Nl82NC9wdGhyZWFkX2NvbmRfdGltZWR3YWl0LlMKLS0tIGdsaWJjLTIu Ny1vcmlnL25wdGwvc3lzZGVwcy91bml4L3N5c3YvbGludXgveDg2XzY0L3B0aHJlYWRfY29uZF90 aW1lZHdhaXQuUwkyMDA3LTExLTI0IDE3OjMyOjUzLjAwMDAwMDAwMCArMDEwMAorKysgZ2xpYmMt Mi43L25wdGwvc3lzZGVwcy91bml4L3N5c3YvbGludXgveDg2XzY0L3B0aHJlYWRfY29uZF90aW1l ZHdhaXQuUwkyMDA3LTExLTI0IDE3OjA3OjA3LjAwMDAwMDAwMCArMDEwMApAQCAtMTM0LDEyICsx MzQsMTQgQEAgX19wdGhyZWFkX2NvbmRfdGltZWR3YWl0OgogCS8qIE9ubHkgY2xvY2tzIDAgYW5k IDEgYXJlIGFsbG93ZWQgc28gZmFyLiAgQm90aCBhcmUgaGFuZGxlZCBpbiB0aGUKIAkgICBrZXJu ZWwuICAqLwogCWxlYXEJMjQoJXJzcCksICVyc2kKKyMgaWZkZWYgU0hBUkVECiAJbW92cQlfX3Zk c29fY2xvY2tfZ2V0dGltZUBHT1RQQ1JFTCglcmlwKSwgJXJheAogCW1vdnEJKCVyYXgpLCAlcmF4 CiAJUFRSX0RFTUFOR0xFICglcmF4KQogCWp6CTI2ZgogCWNhbGwJKiVyYXgKIAlqbXAJMjdmCisj IGVuZGlmCiAyNjoJbW92bAkkX19OUl9jbG9ja19nZXR0aW1lLCAlZWF4CiAJc3lzY2FsbAogMjc6 Cg==