Bugs item #1628484, was opened at 2007-01-05 00:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628484&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bob Atkins (bobatkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Initial Comment:
This looks like a recurring and somewhat sore topic.
For those of us that have been fighting the dreaded:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc config?)."
when performing a 64 bit compile. I believe I have identified the problems. All
of which are directly related to the Makefile(s) that are generated as part of
the configure script. There does not seem to be anything wrong with the
configure script or anything else once all of the Makefiles are corrected
Python will build 64 bit
Although it is possible to pass the following environment variables to
configure as is typical on most open source software:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
headers in a nonstandard directory <include dir>
CPP C preprocessor
These flags are *not* being processed through to the generated Makefiles. This
is where the problem is. configure is doing everything right and generating all
of the necessary stuff for a 64 bit compile but when the compile is actually
performed - the necessary CFLAGS are missing and a 32 bit compile is initiated.
Taking a close look at the first failure I found the following:
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-I. -I./Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
Where are my CFLAGS???
I ran the configure with:
CFLAGS="-O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9 -R/opt/lib/sparcv9" \
CXXFLAGS="-O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9 -R/opt/lib/sparcv9" \
LDFLAGS="-m64 -L/opt/lib/sparcv9 -R/opt/lib/sparcv9" \
./configure --prefix=/opt \
--enable-shared \
--libdir=/opt/lib/sparcv9
Checking the config.log and config.status it was clear that the flags were used
properly as the configure script ran however, the failure is in the various
Makefiles to actually reference the CFLAGS and LDFLAGS.
LDFLAGS is simply not included in any of the link stages in the Makefiles and
CFLAGS is overidden by BASECFLAGS, OPT and EXTRA_CFLAGS!
Ah!
EXTRA_CFLAGS="-O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9 -R/opt/lib/sparcv9" \
make
Actually got the core parts to compile for the library and then failed to build
the library because - LDFLAGS was missing from the Makefile for the library
link stage - :-(
Close examination suggests that the OPT environment variable could be used to
pass the necessary flags through from conifgure but this still did not help the
link stage problems.
The fixes are pretty minimal to ensure that the configure variables are passed
into the Makefile. My patch to the Makefile.pre.in is attached to this bug
report.
Once these changes are made Python will build properly for both 32 and 64 bit
platforms with the correct CFLAGS and LDFLAGS passed into the configure script.
BTW, while this bug is reported under a Solaris/gcc build the patches to
Makefile.pre.in should fix similar build issues on all platforms.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628484&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
