/$scratchfilename=/tmp/canonicalize-whitespace-1.9643.tmp //entering make-host-1.sh //building cross-compiler, and doing first genesis fatal error encountered in SBCL pid 10549(tid 16384): This version of SBCL only works correctly with the NPTL threading library. Please use a newer glibc, use an older SBCL, or stop using LD_ASSUME_KERNEL emerge --info: Portage 2.0.53 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.12-gentoo-r4 x86_64) ================================================================= System uname: 2.6.12-gentoo-r4 x86_64 AMD Opteron(tm) Processor 246 Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/resin/conf /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2" DISTDIR="/opt/no_archive/portage/distfiles" FEATURES="autoconfig buildpkg ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.llarian.net/ ftp://gentoo.llarian.net/pub/gentoo http://gentoo.ccccom.com http://gentoo.osuosl.org/" MAKEOPTS="-j2" PKGDIR="/opt/no_archive/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acl alsa arts audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cups curl doc eds emboss encode esd exif expat fam flac foomaticdb fortran gd gdbm gif glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile idn imagemagick imlib ipv6 java jpeg junit kde lcms libg++ libwww log4cpp lzw lzw-tiff mad mhash mikmod mng motif mozilla mp3 mpeg mysql nas ncurses nls ogg opengl pam pcre pdflib perl plotutils png postgres python qt quicktime readline ruby sdl slang spell ssl svg tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev usb userlocales vorbis wxwindows xine xinerama xml2 xmms xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
I don't have access to a amd64 machine at the moment to verify, but it looks like the upstream binaries we use to bootstrap our own SBCL are starting to be built for NPTL systems. If we continue to use their binaries, then our ebuilds wont be able to create SBCLs even for non NPTL systems. We can either A) start creating our own bootstrap SBCL compilers which work on NPTL and non-NPTL systems B) implement support for using CLISP or CMUCL to build SBCL or C) require users to have ntpl systems. Option A) impacts my time resources significantly. I will have to rebuild SBCLs for all architectures that need it. Its also a problem because when we depart from official binaries, it hard for upstream to help diagnose problems we may encounter (its easier to work with "I tried it with the upstream binaries and we got the same problem...") Option B) wont work for CMUCL since it only supports x86. CLISP is a risky choice, I think. Historically, it has been harder for us to maintain ports for several architecures with CLISP than with SBCL even though CLISP is often thought of as highly portable. Sometimes it is not possible to build SBCL with CLISP (I see mention of this in the Debian changelogs also). Option C) might be unpopular with some users -- requiring NPTL support. NPTL is pretty much the norm though these days.
Same issue with 0.9.10 on amd64. ... /$scratchfilename=/tmp/canonicalize-whitespace-1.4374.tmp //entering make-host-1.sh //building cross-compiler, and doing first genesis fatal error encountered in SBCL pid 5296(tid 16384): This version of SBCL only works correctly with the NPTL threading library. Please use a newer glibc, use an older SBCL, or stop using LD_ASSUME_KERNEL !!! ERROR: dev-lisp/sbcl-0.9.10 failed. Call stack: ebuild.sh, line 1933: Called dyn_compile ebuild.sh, line 971: Called src_compile
What specifically needs to be done to build SBCL with NPTL support? I have been unable to find any documentation on what the USE flag "nptl%" means. Adding USE="nptl" doesn't seem to change the sbcl's use of "nptl%". Neither does adding USE="threads". So, what specifically needs to be done to build with NPTL?
nptl is "Native POSIX Threads Library" which controls glibc build. so add nptl to use use flags and re-emerge glibc then emerge sbcl.
I've added some logic to pkg_setup to ensure that nptl is in use on x86 and amd64 linux.