Re: Python won't build?

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=..., (plus devfs and ports tree). Same problem.
> 
> 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 != 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=athlon64  -fno-strict-aliasing -DNDEBUG -O2 -pipe -march=athlon64  -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  
./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=athlon64  -fno-strict-aliasing -DNDEBUG -O2 -pipe -march=athlon64  -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