From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 01:23:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5F3E106566B for ; Wed, 4 Apr 2012 01:23:51 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (secure.freebsdsolutions.net [69.55.234.48]) by mx1.freebsd.org (Postfix) with ESMTP id 8ACB18FC12 for ; Wed, 4 Apr 2012 01:23:51 +0000 (UTC) Received: from [192.168.2.82] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1.jnielsen.net (8.14.4/8.14.4) with ESMTP id q341NfOv078040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 3 Apr 2012 21:23:42 -0400 (EDT) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: John Nielsen In-Reply-To: <7E2199A3-9E2D-44D5-B7E5-06D68A13D70B@jnielsen.net> Date: Tue, 3 Apr 2012 21:23:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E2199A3-9E2D-44D5-B7E5-06D68A13D70B@jnielsen.net> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1084) X-DCC-sonic.net-Metrics: ns1.jnielsen.net; whitelist Subject: Re: Python won't build? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 01:23:51 -0000 On Mar 31, 2012, at 10:21 PM, John Nielsen wrote: > I updated a machine yesterday from 9-STABLE to 10-CURRENT (r233631). = Everything went smoothly with the update itself, but I ran in to an = issue with Python when rebuilding all of my installed ports. Python = won't build; it complains about the definition of LONG_BIT. I had = python27 installed but python26 does the same thing. I ran "make = delete-old" and "make delete-old-libs", no improvement. I even built a = clean chroot environment via make installworld DESTDIR=3D..., (plus = devfs and ports tree). Same problem. >=20 > So.. is this the result of something in the FreeBSD source? Can anyone = else reproduce this? What should I try next? So, no chorus of "me too"s. How about a "works for me"? I'm still not = sure if this is something peculiar to this machine or not and I haven't = fired up a clean virtual machine on different hardware to verify (though = I'm not far from that...). Some of my own follow up: I tried rebuilding world with sources from today, 3/9 and 2/28 and got = the same result, so if it's a regression on the FreeBSD end it's been = there a while (and seemingly not related to the i386/amd64/x86 header = cleanup, which led me to pick those revisions). I also tried setting = tweaking newvers.sh to say 9.9-CURRENT and rebuilt world with no = improvement, so if it's autotools or something else versus two-digit = FreeBSD version problem it's something subtle. Looking in to the Python code, this block is what throws the error: /* from python27/work/Python-2.7.2/Include/pyport.h */ #ifndef LONG_BIT #define LONG_BIT (8 * SIZEOF_LONG) #endif #if LONG_BIT !=3D 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at = compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc = config?)." #endif It turns out the problem is not the one mentioned in the comment (bogus = definition of LONG_BIT), but rather that SIZEOF_LONG is never defined. = Comparing with another amd64 system running 9-STABLE, it looks like that = ought to be defined during the "configure" step and end up in = work/Python-2.7.2/portbld.shared/pyconfig.h. That is not happening on = the maching running -CURRENT--pyconfig.h doesn't get created in the = portbld.shared directory. It does exist in portbld.static (and on the = well-behaving -STABLE machine the two are identical), so I copied it = over. That lets the first stage of the build mostly finish but it fails = linking the 'python' binary: cc -c -fno-strict-aliasing -O2 -pipe -march=3Dathlon64 = -fno-strict-aliasing -DNDEBUG -O2 -pipe -march=3Dathlon64 = -fno-strict-aliasing -I. -IInclude -I./../Include -fPIC -DPy_BUILD_CORE = -o Modules/python.o ./../Modules/python.c cc -pthread -Wl,--export-dynamic -o python Modules/python.o -L. = -lpython2.7 -lutil -lm =20 ./libpython2.7.so: undefined reference to `_PyImport_Inittab' *** [python] Error code 1 Stop in = /opt/scratch/opt/ports/lang/python27/work/Python-2.7.2/portbld.shared. *** [pre-build] Error code 1 So there is something going on besides just the header file not being = created. Does anyone have any ideas what it could be? I'm willing to = believe this is a Python problem but I'd still like to know what changed = on my end to uncover it before pursuing help from the Python folks. > cc -c -fno-strict-aliasing -O2 -pipe -march=3Dathlon64 = -fno-strict-aliasing -DNDEBUG -O2 -pipe -march=3Dathlon64 = -fno-strict-aliasing -I. -IInclude -I./../Include -fPIC -DPy_BUILD_CORE = -o Parser/acceler.o ./../Parser/acceler.c > ... > In file included from ./../Include/Python.h:58, > from ./../Include/pgenheaders.h:10, > from ./../Parser/acceler.c:13: > ./../Include/pyport.h:849:2: error: #error "LONG_BIT definition = appears wrong for platform (bad gcc/glibc config?)." > ... > Stop in = /opt/scratch/opt/ports/lang/python27/work/Python-2.7.2/portbld.shared. > *** [pre-build] Error code 1 Thanks, JN