Hi Martin,

This is what you get when you try to build a 64-bit Python on a biarch
machine (64-bit kernel, 32-bit userspace), using a gcc that generates
natively 32-bit objects (therefore, you *must* pass the '-m64' option
for the compiler):

#> ./configure --enable-shared --target=powerpc64-unknown-linux
BASECFLAGS='-m64'

<output generated by configure script>

#> make

gcc -pthread -c -m64 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3
-Wall -Wstrict-prototypes  -I. -IInclude -I./Include  -fPIC
-DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from Include/Python.h:57,
                 from ./Modules/python.c:3:
Include/pyport.h:761:2: error: #error "LONG_BIT definition appears wrong
for platform (bad gcc/glibc config?)."
make: *** [Modules/python.o] Error 1


As you can see, the compilation fails. Now, if I try this configure line:

#> ./configure --enable-shared --target=powerpc64-unknown-linux
BASECFLAGS='-m64' CFLAGS='-m64'

<output from configure>

#> make

Compilation goes well untill:

gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  
Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o
Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o
Python/mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o
Parser/pgenmain.o -lpthread -ldl  -lutil -o Parser/pgen

As you can see, in this specific line we don't have the '-m64' flag,
what causes a bunch of errors (all of them due to the absence of '-m64'
flag). Ok, so I decided to try with LDFLAGS:

#> ./configure --enable-shared --target=powerpc64-unknown-linux
BASECFLAGS='-m64' CFLAGS='-m64' LDFLAGS='-m64'

<output from configure>

#> make

Now, the error happens when libpython.so is generated (and the reason is
the same: missing '-m64').

Well, now I have a few questions:

1) As you could see above, actually you need CFLAGS in order to compile
Python correctly. As far as I could investigate, the reason you need
this is because of the tests that are done by configure. Without the
CFLAGS, configure will think it's building a 32-bit Python, despite of
the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS
through Makefile or not? IMHO, we do.

2) Even with CFLAGS and BASECFLAGS set, the compilation fails. Using
LDFLAGS makes the compilation process continue a little more, but it
still doesn't solve the problem. AFAIK, the reason it doesn't solve the
problem is, again, because we are not propagating it through the
Makefile. Can you see any different reason? Also, should we propagate
LDFLAGS through Makefile? IMHO, we should.

Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'.
But again, I don't think this is a solution for this issue :-).