Summary: | Cannot update Python on newly installed system | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sascha Silbe <sascha-gentoo-bugzilla> |
Component: | [OLD] Core system | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED INVALID | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Build script for "emerge -Duv system"
config.log (bzipped) |
Description
Sascha Silbe
2004-02-01 04:58:26 UTC
Created attachment 24728 [details]
Build script for "emerge -Duv system"
The script of the full installation is available at http://sascha.silbe.org/gentoo/bug40062-python-update-problem.script.bz2 in case you need it. i've never seen that before .. does your glibc have ipv6 support? Since the glibc ebuild does not parse the 'ipv6' USE flag, I expect it has unconditional IPv6 support: aero level3 # qpkg -I -v glibc sys-libs/glibc-2.3.2-r9 * aero level3 # grep ipv6 /usr/portage/sys-libs/glibc/glibc-2.3.2-r9.ebuild aero level3 # This problems happens reproducably on the automatically installed system, but not on my desktop system (which has USE=ipv6 set, too). It might have something to do with the fact that I'm using a generic stage3 tarball for installation and update make.conf (i.e. change USE flags) before updating the base system. It's getting even more strange. It seems the 'ipv6' USE flag is set by default, so it has NOT changed during the installation: sascha@cube:/usr/src/gentoo-build/catalyst/targets/stage3$ grep GRP_STAGE23_USE /etc/make.profile/make.defaults GRP_STAGE23_USE="ipv6 pam tcpd readline nls ssl gpm perl python berkdb acl ncurses" i'm pretty certain python-2.3 builds from stage2 and stage3 from gentoo-1.4 and also the experimental stages. thats one of the regressions that i tested when it was bumped to stable. can you attach the config.log for the python build? Created attachment 25005 [details]
config.log (bzipped)
The config.log does not contain anything really useful about the issue, but
I've attached it anyway.
If I execute the test code manually, it returns "0", i.e. working getaddrinfo: aero root # gcc -Wall -o getaddrinfo-test getaddrinfo-test.c ; ./getaddrinfo-test ; echo $? getaddrinfo-test.c:8: warning: return type defaults to `int' getaddrinfo-test.c: In function `main': getaddrinfo-test.c:78: warning: implicit declaration of function `exit' 0 So why is it failing during autoconf? i dunno, i've never encoutered a bugger getaddrinfo, have you tried compiling glibc with less agressive CFLAGS, like -O1 or -O2 ? Sascha, is this still a problem or is it fixed? I'll try it again in a few days. Currently gcc is giving me a headache ("emerge foopkg gcc barpkg" bails out in barpkg with a non-working C compiler). OK, I've found the problem. It's something totally different, nothing even hinted at it: /etc was not world-readable, so the portage user could not access it. Python now seems to compile cleanly on that system. |