On a system freshly installed by my automated installer (using an up-to-date stage3 tarball built by catalyst), "emerge -Du system" fails to update Python: [...] checking for major... yes checking for getaddrinfo... yes checking getaddrinfo bug... buggy Fatal: You must get working getaddrinfo() function. or you can specify "--disable-ipv6". !!! ERROR: dev-lang/python-2.3.3 failed. !!! Function econf, Line 339, Exitcode 1 !!! econf failed Reproducible: Always Steps to Reproduce: 1. Install a new system from an up-to-date stage3 tarball. 2. Set USE=ipv6 3. emerge -Du system Actual Results: See attached build script. Expected Results: Build Python 2.3.3 with IPv6 support. Portage 2.0.49-r21 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r9, 2.4.22-uml-cube-2-5um) ================================================================= System uname: 2.4.22-uml-cube-2-5um i686 UML Gentoo Base System version 1.4.3.10 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=k6 -O3 -pipe" CHOST="i586-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox strict userpriv usersandbox" GENTOO_MIRRORS="http://192.168.1.2/gentoo/ ftp://ftp.easynet.nl/mirror/gentoo/ http://gentoo.inode.at/ ftp://gentoo.inode.at/source/ " MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://hybrid.sascha.silbe.org/gentoo-portage" USE="acl berkdb crypt doc gdbm ipv6 jpeg maildir mbox ncurses nls oggvorbis pam png python readline ssl unicode x86 xml xml2 zlib linguas_en_US linguas_en_GB linguas_en linguas_de_DE linguas_de"
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.