Python build finished, but the necessary bits to build these modules were not found: bsddb185 dl imageop sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: crypt nis running build_scripts creating build/scripts-2.7 copying and adjusting /tmp/portage/dev-lang/python-2.7.2/work/Python-2.7.2/Tools/scripts/pydoc -> build/scripts-2.7 copying and adjusting /tmp/portage/dev-lang/python-2.7.2/work/Python-2.7.2/Tools/scripts/idle -> build/scripts-2.7 copying and adjusting /tmp/portage/dev-lang/python-2.7.2/work/Python-2.7.2/Tools/scripts/2to3 -> build/scripts-2.7 copying and adjusting /tmp/portage/dev-lang/python-2.7.2/work/Python-2.7.2/Lib/smtpd.py -> build/scripts-2.7 changing mode of build/scripts-2.7/pydoc from 644 to 755 changing mode of build/scripts-2.7/idle from 644 to 755 changing mode of build/scripts-2.7/2to3 from 644 to 755 changing mode of build/scripts-2.7/smtpd.py from 644 to 755 make: *** [sharedmods] Error 1 emake failed * ERROR: dev-lang/python-2.7.2 failed (compile phase): * emake failed * * Call stack: * ebuild.sh, line 62: Called call-ebuildshell 'src_compile' * environment, line 1426: Called src_compile * environment, line 5988: Called die * The specific snippet of code: * emake EPYTHON="python${PV%%.*}" || die "emake failed" * * If you need support, post the output of 'emerge --info =dev-lang/python-2.7.2', * the complete build log and the output of 'emerge -pqv =dev-lang/python-2.7.2'.
Created attachment 285081 [details] /mnt/tmpfs/python-2.7.2:20110830-124413.log build.log
Portage 2.2.01.18826-prefix (prefix/linux/amd64, gcc-4.5.2, unavailable, 2.6.34.7-0.5-desktop x86_64) ================================================================= System Settings ================================================================= System uname: Linux-2.6.34.7-0.5-desktop-x86_64-Intel-R-_Xeon-R-_CPU_E5504_@_2.00GHz-with-SuSE-11.3-x86_64 Timestamp of tree: Tue, 30 Aug 2011 11:41:04 +0000 app-shells/bash: 4.2_p10 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.6.5-r2, 2.7.1-r1 dev-util/cmake: 2.8.4-r1 dev-util/pkgconfig: 0.25-r2 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.21.51.0.7 sys-devel/gcc: 4.5.2-r00.1 sys-devel/gcc-config: 1.4.1-r00.2 sys-devel/libtool: 2.4-r01.1 sys-devel/make: 3.82 sys-kernel/linux-headers: 2.6.38 Repositories: gentoo_prefix last-hope science Installed sets: ACCEPT_KEYWORDS="~amd64-linux" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=core2 -mssse3 -frecord-gcc-switches -g" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/scisoft64/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/portage /etc/revdep-rebuild /etc/terminfo /opt/scisoft64/etc/env.d" CXXFLAGS="-O2 -pipe -march=core2 -mssse3 -frecord-gcc-switches -g" DISTDIR="/opt/scisoft64/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="-v -t --jobs=12 --load-average=12 --keep-going --autounmask --autounmask-write" FEATURES="assume-digests binpkg-logs collision-protect distlocks ebuild-locks fixlafiles fixpackages news noinfo noman parallel-fetch preserve-libs protect-owned sfperms split-log splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe -march=core2 -mssse3 -frecord-gcc-switches -g" GENTOO_MIRRORS=" http://gentoo.j-schmitz.net/mirror/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://ftp.tu-clausthal.de/pub/linux/gentoo/" LANG="en_US.UTF-8" LDFLAGS="-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common" MAKEOPTS="-j12 -l12" PKGDIR="/opt/scisoft64/usr/portage/packages" PORTAGE_COMPRESS="lzma" PORTAGE_COMPRESS_FLAGS="-z -9 -f -S .lzma -v" PORTAGE_CONFIGROOT="/opt/scisoft64/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/opt/scisoft64/var/tmp" PORTDIR="/opt/scisoft64/usr/portage" PORTDIR_OVERLAY="/opt/scisoft64/data/lh /opt/scisoft64/data/sci" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="amd64 apbs atlas berkdb bzip2 cli cracklib crypt cxx dri extendnmr fortran gdbm gmp iconv jpeg mmx modules mudflap ncurses nis nls nptl nptlonly opengl openmp pcre perl png pppd prefix pymol python qt3support readline session sse sse2 ssl sysfs tcpd threads tiff unicode xorg zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="none" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS
Probably this issue http://bugs.python.org/issue9762 Can we get a backport to 2.7?
http://bugs.python.org/issue11715 this is the bug which has the real patch/fix.
I don't see how the multiarch thing can possibly fix anything. In Prefix it typically screws things up, instead.
*** Bug 373539 has been marked as a duplicate of this bug. ***
I've found out, that the module-libraries aren't even linked to the libraries they need most. On a native gentoo system, I got: $ ldd crypt.so ... libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7690000) ... $ equery b /lib/libcrypt.so.1 * Searching for /lib/libcrypt.so.1 ... sys-libs/glibc-2.12.2 (/lib/libcrypt-2.12.2.so) sys-libs/glibc-2.12.2 (/lib/libcrypt.so.1 -> libcrypt-2.12.2.so) $ ldd nis.so ... libnsl.so.1 => /lib/libnsl.so.1 (0xb7713000) ... $ equery b /lib/libnsl.so.1 * Searching for /lib/libnsl.so.1 ... sys-libs/glibc-2.12.2 (/lib/libnsl.so.1 -> libnsl-2.12.2.so) sys-libs/glibc-2.12.2 (/lib/libnsl-2.12.2.so) But crypt_failed.so and nis_failed.so in the prefix build dir just linked to the default libraries (which I excluded up there) and not the ones that define the symbols they need especially. So I worked around it, by exporting LDFLAGS="-L/usr/lib64 -L/lib64" (Propably I should use some rpath here...)
ok, so it feels like python does a search itself, and doesn't use {,/usr}/lib64 or something.
I see the same failure when trying to bootstrap Gentoo Prefix on OpenSUSE 11.4, on an x86_64 host, at the step ./bootstrap-prefix.sh $EPREFIX/tmp python which tries to build Python 2.7.2.
(In reply to comment #9) > I see the same failure when trying to bootstrap Gentoo Prefix on OpenSUSE 11.4, > on an x86_64 host, at the step > > ./bootstrap-prefix.sh $EPREFIX/tmp python > > which tries to build Python 2.7.2. Robbe, try LDFLAGS="-L/usr/lib64 -L/lib64" ./bootstrap-prefix.sh $EPREFIX/tmp python (given you have libcrypt and libnls somewhere in {,/usr}/lib64)
Moritz, I tried your recipe but bootstrapping still fails with > Failed to build these modules: > crypt nis There are several crypt- and nis-related files on the system, > ls -ld /usr/lib64/*crypt* /lib64/*crypt* /usr/lib64/*nis* /lib64/*nis* -rwxr-xr-x 1 root root 57652 Feb 22 2011 /lib64/libcrypt-2.11.3.so lrwxrwxrwx 1 root root 18 Mar 2 2011 /lib64/libcrypt.so.1 -> libcrypt-2.11.3.so -r-xr-xr-x 1 root root 1757112 Feb 19 2011 /lib64/libcrypto.so.1.0.0 lrwxrwxrwx 1 root root 22 Mar 2 2011 /lib64/libcryptsetup.so.1 -> libcryptsetup.so.1.1.0 -rwxr-xr-x 1 root root 97496 Feb 19 2011 /lib64/libcryptsetup.so.1.1.0 lrwxrwxrwx 1 root root 19 Mar 2 2011 /lib64/libgcrypt.so.11 -> libgcrypt.so.11.6.0 -rwxr-xr-x 1 root root 503584 Feb 18 2011 /lib64/libgcrypt.so.11.6.0 -rwxr-xr-x 1 root root 52529 Feb 22 2011 /lib64/libnss_nis-2.11.3.so lrwxrwxrwx 1 root root 20 Mar 2 2011 /lib64/libnss_nis.so.2 -> libnss_nis-2.11.3.so -rwxr-xr-x 1 root root 61767 Feb 22 2011 /lib64/libnss_nisplus-2.11.3.so lrwxrwxrwx 1 root root 24 Mar 2 2011 /lib64/libnss_nisplus.so.2 -> libnss_nisplus-2.11.3.so lrwxrwxrwx 1 root root 18 Mar 2 2011 /lib64/libxcrypt.so.2 -> libxcrypt.so.2.0.0 -rwxr-xr-x 1 root root 22896 Feb 18 2011 /lib64/libxcrypt.so.2.0.0 drwxr-xr-x 2 root root 4096 Mar 2 2011 /lib64/xcrypt -rw-r--r-- 1 root root 261996 Feb 22 2011 /usr/lib64/libcrypt.a lrwxrwxrwx 1 root root 20 Oct 4 16:28 /usr/lib64/libcrypt.so -> /lib64/libcrypt.so.1 lrwxrwxrwx 1 root root 25 Oct 4 16:29 /usr/lib64/libcrypto.so -> /lib64/libcrypto.so.1.0.0 lrwxrwxrwx 1 root root 18 Mar 2 2011 /usr/lib64/libk5crypto.so.3 -> libk5crypto.so.3.1 -rwxr-xr-x 1 root root 162704 Feb 19 2011 /usr/lib64/libk5crypto.so.3.1 lrwxrwxrwx 1 root root 22 Oct 4 16:28 /usr/lib64/libnss_nis.so -> /lib64/libnss_nis.so.2 lrwxrwxrwx 1 root root 26 Oct 4 16:28 /usr/lib64/libnss_nisplus.so -> /lib64/libnss_nisplus.so.2
I'm getting similar errors on CentOS release 5.6 (Final). (In reply to comment #11) > Moritz, I tried your recipe but bootstrapping still fails with > > > Failed to build these modules: > > crypt nis > > There are several crypt- and nis-related files on the system, > > > ls -ld /usr/lib64/*crypt* /lib64/*crypt* /usr/lib64/*nis* /lib64/*nis* > -rwxr-xr-x 1 root root 57652 Feb 22 2011 /lib64/libcrypt-2.11.3.so > lrwxrwxrwx 1 root root 18 Mar 2 2011 /lib64/libcrypt.so.1 -> > libcrypt-2.11.3.so > -r-xr-xr-x 1 root root 1757112 Feb 19 2011 /lib64/libcrypto.so.1.0.0 > lrwxrwxrwx 1 root root 22 Mar 2 2011 /lib64/libcryptsetup.so.1 -> > libcryptsetup.so.1.1.0 > -rwxr-xr-x 1 root root 97496 Feb 19 2011 /lib64/libcryptsetup.so.1.1.0 > lrwxrwxrwx 1 root root 19 Mar 2 2011 /lib64/libgcrypt.so.11 -> > libgcrypt.so.11.6.0 > -rwxr-xr-x 1 root root 503584 Feb 18 2011 /lib64/libgcrypt.so.11.6.0 > -rwxr-xr-x 1 root root 52529 Feb 22 2011 /lib64/libnss_nis-2.11.3.so > lrwxrwxrwx 1 root root 20 Mar 2 2011 /lib64/libnss_nis.so.2 -> > libnss_nis-2.11.3.so > -rwxr-xr-x 1 root root 61767 Feb 22 2011 /lib64/libnss_nisplus-2.11.3.so > lrwxrwxrwx 1 root root 24 Mar 2 2011 /lib64/libnss_nisplus.so.2 -> > libnss_nisplus-2.11.3.so > lrwxrwxrwx 1 root root 18 Mar 2 2011 /lib64/libxcrypt.so.2 -> > libxcrypt.so.2.0.0 > -rwxr-xr-x 1 root root 22896 Feb 18 2011 /lib64/libxcrypt.so.2.0.0 > drwxr-xr-x 2 root root 4096 Mar 2 2011 /lib64/xcrypt > -rw-r--r-- 1 root root 261996 Feb 22 2011 /usr/lib64/libcrypt.a > lrwxrwxrwx 1 root root 20 Oct 4 16:28 /usr/lib64/libcrypt.so -> > /lib64/libcrypt.so.1 > lrwxrwxrwx 1 root root 25 Oct 4 16:29 /usr/lib64/libcrypto.so -> > /lib64/libcrypto.so.1.0.0 > lrwxrwxrwx 1 root root 18 Mar 2 2011 /usr/lib64/libk5crypto.so.3 -> > libk5crypto.so.3.1 > -rwxr-xr-x 1 root root 162704 Feb 19 2011 /usr/lib64/libk5crypto.so.3.1 > lrwxrwxrwx 1 root root 22 Oct 4 16:28 /usr/lib64/libnss_nis.so -> > /lib64/libnss_nis.so.2 > lrwxrwxrwx 1 root root 26 Oct 4 16:28 /usr/lib64/libnss_nisplus.so -> > /lib64/libnss_nisplus.so.2
Is there anybody who can give me access to such system where it fails? I really would like to fix this problem :/
Fabian, You can have a freshly installed and updated scientific linux 6.1 You can have sudo for yum but please document which packages you are installing to get this running You can have a normal user account to set this up if that's okey for you go ahead... post your ssh public key and desired username and I'll post where to connect to, when I have set you up... I really want this bug to be fixed... we're about to use Scientific Linux 6.1 on our cluster in the future and I'm planning to use gentoo prefix to provide somewhat optimized but mainly more up-to-date binaries (or binaries that aren't readily avaliable on sl)... this bug also affects sl6.1 and therefor probably also centos 6.1 and rhel 6.1 besides the mentioned suse... maybe the solution is common so.... I tried installing prefix on such a linux but it didn't work... i could get around the python bug by explicitly setting the right ldflags but the very same problem happened again when i started emerging stuff after the bootstrap... and not only with python... so this might not be a python problem at all but a problem with how prefix and the linker work together on these enterprise linuxes... maybe selinux comes into play or whatever... anyway you'd be free to hack away on this you're in? :) Best, Dominik
Dominik, I'll contact you off-list ;)
(In reply to comment #9) > I see the same failure when trying to bootstrap Gentoo Prefix on OpenSUSE 11.4, > on an x86_64 host, at the step > > ./bootstrap-prefix.sh $EPREFIX/tmp python > > which tries to build Python 2.7.2. On the i686 machine provided by Dominik, this already went fine. I suspect a 64-bits (multilib) machine is necessary to reproduce this bug.
Bootstrap on i686 Scientific Linux was successful.
I managed to avoid the issue by using -ssl when emerging python. I am on Fedora 15 64bit.
Ignore my previous comment; this seemed to work due to the fact that I'd run an emerge --sync before I was supposed to. I have yet to get the install working.
*** Bug 389281 has been marked as a duplicate of this bug. ***
ok, I finally hit this problem on Dominik's machine. It's during bootstrap time, so that explains why fixes won't work.
This appears to be just another variant of Python's stupidities. I just finished testing a fix to the bootstrap script right now.
For some reason, newer debian/redhat/etc don't install libcrypt.so in /lib any more (the 32-bits version), but only in /lib64. Since Python's setup.py is stupid enough not to rely on the linker, it only searches /lib for names, and hence doesn't find crypt and co. This explains why this problem doesn't occur on Solaris and Darwin. Maybe the simplest way around this is to add /lib, /lib32 and /lib64 to the searchpath always.
Ok. thanks to Dominik's system, finally found and solved this bug for real. I'm finishing the bootstrap on his machine right now, and will close this bug if I manage to finish the emerge -e stage.
bootstrap tree updated to include necessary fixes bootstrapping confirmed to work correctly again Thanks all for the input.
Thanks Fabian! I'll try the new bootstrap script on the many machines/distros we have access to and report bugs if any.
Created attachment 313477 [details] Build log failure for Python
Hi All, I'm still not able to build Python, and this is the closes bug I've found to my problem, although not identical. I've attached a complete log, however a shorter summary is presented below: ~/gentoo> LDFLAGS="-L/usr/lib64 -L/lib64" ../bin/bootstrap-prefix.sh $EPREFIX/tmp python ... Python build finished, but the necessary bits to build these modules were not found: _bsddb _sqlite3 _ssl _tkinter bsddb185 dl imageop sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: bz2 ... make: *** [sharedmods] Error 1 Nima
Also note, the system details are (unfortunately) as follows: % cat /etc/SuSE-release SUSE Linux Enterprise Server 10 (x86_64) VERSION = 10 PATCHLEVEL = 2 % uname -a Linux appsyd800 2.6.16.60-0.27.LSG.420898.1-smp #1 SMP Thu Aug 28 04:16:48 UTC 2008 x86_64 x86_64 x86_64 GNU/Linux
~/gentoo> cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 1 ~/gentoo> cat /etc/SuSE-brand SLES VERSION = 11 CO-BRANDS = SLE openSUSE ~/gentoo> uname -a Linux devsyd899 2.6.32.12-0.7-default #1 SMP 2010-05-20 11:14:20 +0200 x86_64 GNU/Linux
Please delete comment 29 (I had not way of editing it, hence added comment 30), and then this one (31).
If your bug is not identical, then please open up a new bug! I see you use 'LDFLAGS="-L/usr/lib64 -L/lib64"', I hope you have a very good reason for doing so, but likely your python build failure is caused by this, which makes the bug invalid.
perhaps this bug is related to bug 414469? Did your python or gcc install things into EPREFIX/usr/lib and also into EPREFIX/usr/lib64?
Hi Fabien, New bug report submitted: https://bugs.gentoo.org/show_bug.cgi?id=418093 ...and I have not used the LDFLAGS override in this new bug report - it's exactly as per the instructions detailed in http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml now.
Justin I've responded to your comment in the new bug page (bug 418093) to keep it all together there: https://bugs.gentoo.org/show_bug.cgi?id=418093 in case the above doesn't get auto-linked.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=f29dafd086fdc9bc1cc505d9ac8fe849d65bcb8d commit f29dafd086fdc9bc1cc505d9ac8fe849d65bcb8d Author: Michael Haubenwallner <haubi@gentoo.org> AuthorDate: 2018-01-22 15:37:15 +0000 Commit: Michael Haubenwallner <haubi@gentoo.org> CommitDate: 2018-01-22 15:38:00 +0000 dev-lang/python: can use elibc_glibc, not amd64-linux This must have been broken since https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=1896ea58f9eef2916986ade1d46aa3e727fbccc7 Bug: https://bugs.gentoo.org/381163 Bug: https://bugs.gentoo.org/473520 Package-Manager: Portage-2.3.19, Repoman-2.3.6 dev-lang/python/Manifest | 4 ++-- dev-lang/python/python-2.7.14.ebuild | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-)}
