Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 198949 - sys-libs/glibc-2.7: static compilation while using pthread_cond_timedwait() fails
Summary: sys-libs/glibc-2.7: static compilation while using pthread_cond_timedwait() f...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL: http://sources.redhat.com/bugzilla/sh...
Whiteboard:
Keywords:
: 199866 200280 200497 200635 200828 200910 201645 201806 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-12 17:09 UTC by jbibollet
Modified: 2007-12-10 01:32 UTC (History)
12 users (show)

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


Attachments
A patch for glibc to fix the problem. (glibc.patch,742 bytes, patch)
2007-11-24 19:31 UTC, Michal Januszewski (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jbibollet 2007-11-12 17:09:41 UTC
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
Comment 1 Vasiliy Levykin 2007-11-13 08:21:47 UTC
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.
Comment 2 Michal Januszewski (RETIRED) gentoo-dev 2007-11-13 16:15:42 UTC
Confirmed. This seems to be a glibc-2.7 problem.
Comment 3 Davide Pesavento gentoo-dev 2007-11-13 21:47:12 UTC
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.
Comment 4 SpanKY gentoo-dev 2007-11-14 04:24:53 UTC
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);}
Comment 5 Michal Januszewski (RETIRED) gentoo-dev 2007-11-14 18:07:46 UTC
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.
Comment 6 SpanKY gentoo-dev 2007-11-14 20:16:26 UTC
ive asked upstream, but i cant promise things look good
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2007-11-21 09:39:46 UTC
*** Bug 199866 has been marked as a duplicate of this bug. ***
Comment 8 Michal Januszewski (RETIRED) gentoo-dev 2007-11-24 19:31:59 UTC
Created attachment 136911 [details, diff]
A patch for glibc to fix the problem.
Comment 9 Senuma Takahiko 2007-11-25 09:12:46 UTC
(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).
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2007-11-25 13:33:40 UTC
*** Bug 200280 has been marked as a duplicate of this bug. ***
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2007-11-27 09:38:29 UTC
*** Bug 200497 has been marked as a duplicate of this bug. ***
Comment 12 Charlie Gehlin 2007-11-27 12:39:14 UTC
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
Comment 13 Jakub Moc (RETIRED) gentoo-dev 2007-11-28 14:25:59 UTC
*** Bug 200635 has been marked as a duplicate of this bug. ***
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2007-11-30 16:24:09 UTC
*** Bug 200828 has been marked as a duplicate of this bug. ***
Comment 15 Michal Januszewski (RETIRED) gentoo-dev 2007-12-01 09:09:39 UTC
(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`?
Comment 16 Jakub Moc (RETIRED) gentoo-dev 2007-12-01 11:07:39 UTC
*** Bug 200910 has been marked as a duplicate of this bug. ***
Comment 17 Jakub Moc (RETIRED) gentoo-dev 2007-12-08 08:44:34 UTC
*** Bug 201645 has been marked as a duplicate of this bug. ***
Comment 18 Jakub Moc (RETIRED) gentoo-dev 2007-12-09 21:41:23 UTC
*** Bug 201806 has been marked as a duplicate of this bug. ***