Summary: | sys-libs/glibc-2.7: static compilation while using pthread_cond_timedwait() fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | jbibollet <bilbotux> |
Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | charlie, claus.boehmer, czarkoff, daemon, dagger, dschridde+gentoobugs, eric_chaligny, f5d8fd51ed1e804c9e8d0357e8614e0493b06e96, hongqn, pesa, satana.hell, spock |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://sources.redhat.com/bugzilla/show_bug.cgi?id=5465 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | A patch for glibc to fix the problem. |
Description
jbibollet
2007-11-12 17:09:41 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. 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. *** |