Bugs item #1306248, was opened at 2005-09-27 21:04
Message generated for change (Comment added) made by jestone
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&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: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John Stone (jestone)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 64-bit Solaris 9 build instructions to README
Initial Comment:
It would be helpful to add the correct 64-bit Solaris 9
build flags to the README file. I'm still working
through problems with Solaris 10, but these flags
seemed to work well for Solaris 9. One could replace
the "-native64" with "-generic64" for maximum binary
compatibility if necessary: (csh syntax env commands below)
setenv CC cc
setenv CXX CC
setenv BASECFLAGS "-native -xarch=native64 -mt -xO3"
setenv LDFLAGS "-xarch=native64"
./configure --without-cxx
----------------------------------------------------------------------
>Comment By: John Stone (jestone)
Date: 2005-09-29 16:41
Message:
Logged In: YES
user_id=48806
I understand your reluctance to add cruft to the README, but
given that there's no "configure --64-bit --without-gcc"
that works, I think that adding something to the docs would
be helpful. There's already a history of documenting
bugs/limitations of the Python build system in the README,
so while I agree with your view that fixing the build system
would be best, adding something to the README is a good
short-term solution until the 64-bit build kinks are fixed
up. I suggest adding something along the lines of what has
already been done for AIX/HP-UX 64-bit builds, since those
also require unusual steps. Keep it short like these?:
AIX 5.3: To build a 64-bit version with IBM's compiler, I
used the
following:
export PATH=/usr/bin:/usr/vacpp/bin
./configure --with-gcc="xlc_r -q64"
--with-cxx="xlC_r -q64" --disable-ipv6 AR="ar -X64"
make
HP-UX: When using threading, you may have to add
-D_REENTRANT to the
OPT variable in the top-level Makefile; reported by
Pat Knight,
this seems to make a difference (at least for HP-UX
10.20)
even though pyconfig.h defines it. This seems
unnecessary when
using HP/UX 11 and later - threading seems to work
"out of the
box".
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-09-29 16:06
Message:
Logged In: YES
user_id=21627
I'm hesitant to add instructions to the README of the style
"do this to get it work", especially when I believe these
instructions are either wrong or overspecified. Adding
something like "Jone Stone <[EMAIL PROTECTED]> suggests
to use these options" might be a compromise.
As for why --without-gcc causes dropping of compiler flags:
It's because of this fragment of configure.in:
AC_MSG_CHECKING(for --without-gcc)
AC_ARG_WITH(gcc,
AC_HELP_STRING(--without-gcc,never use gcc),
[
case $withval in
no) CC=cc
without_gcc=yes;;
Not sure what caused the introduction of this fragment, but
omitting --without-gcc looks like the right thing to do.
In general, I would much more prefer to receive patches that
make things work out of the box, instead of documenting bugs.
----------------------------------------------------------------------
Comment By: John Stone (jestone)
Date: 2005-09-29 15:12
Message:
Logged In: YES
user_id=48806
Of course there't no single set of options, that much is
true of any platform.
However, I've provided one set of options that does work.
It's clear to me that little testing is being done building
Python for the 64-bit ABI mode of targets such as IRIX,
Solaris, and other platforms using the vendor compilers.
(maybe gcc works, but I can't use gcc...) In the case of
the other platforms, there are comments in the README that
are helpful to those of us that need to build a 64-bit
Python interpreter for embedding in 64-bit applications.
Several Python 2.3 versions I tried fail to pass on build
flags to some of the module builds, proving that nobody
tested this in the past. 2.4.2c1 works, but you have to set
all of these environment variables to get it to work.
Anyway, as far as the options I selected: You could choose
-O but the Sun compilers prefer -xO3 (some old versions
whine at you if you use -O). I chose -mt for thread safety,
which is already documented in the Python README. Simply
setting CC to "cc -xarch=native64" worked way back in Python
2.2, but fails with 2.3.x and 2.4.x. If you try that on
2.4.2c1 and use the configure flags below,
setenv CC "cc -xarch=native64"
./configure --without-cxx --without-gcc
You can see that the build scripts have already lost the
-xarch=native64 in the first couple of compiles:
cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o
Parser/metagrammar.o Parser/metagrammar.c
cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o
Parser/firstsets.o Parser/firstsets.c
cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o
Parser/grammar.o Parser/grammar.c
If I eliminate the "--without-gcc" flag to configure, the
build does work
by setting CC to "cc -xarch=native64". I don't know why it
breaks when one adds --without-gcc, but it'd be nice if the
docs cleared this up.
With Python 2.2, adding --without-gcc did not break the build.
This is exactly the problem with the current state of the
build system and docs. I don't mind the fact that it's a
little hokey to get the build done, but it'd be nice if the
docs contained the facts needed to do this without a
trial-and-error based search of the configuration space to
avoid the bugs in the build system.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-09-29 06:41
Message:
Logged In: YES
user_id=21627
I believe there is no single set of "correct" options. E.g.
why is it necessary to pass -xO3? I'm sure it will build
fine without that; also, -O is documented to expand to -xO3.
Likewise, why -mt? configure should figure out the necessary
libraries itself, and -mt links with -lthread, when it
really should link with -lpthread.
-native is documented as synonym for -xtarget=native. This
in turn isn't documented much, but if it included
-xarch=native, I don't understand why you want that: it is
documented as "The compiler chooses the appropriate setting
for producing 32-bit binaries".
IOW, I think that setting CC to "cc -xarch=native64" should
be enough. Unfortunately, I don't have a Sun compiler on
Solaris, so I personally use gcc instead.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
