This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2006年03月15日 23:36 by johnwgrove, last changed 2022年04月11日 14:56 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| configure.in | johnwgrove, 2006年03月15日 23:36 | Python-2.4.2/configure.in | ||
| Messages (3) | |||
|---|---|---|---|
| msg27788 - (view) | Author: John W. Grove (johnwgrove) | Date: 2006年03月15日 23:36 | |
The configure script for Python 4.2.2 add the compiler
flags -Wno-long-double and -no-cpp-precomp when using
the Gnu gcc compiler on Darwin. This causes the build
to fail when using versions of GCC build directly from
Gnu source (for example gcc-4.0.2 and gcc-4.1). These
options are only available when using the "native" gcc
compilers supplied with the Darwin OS. In particular I
am using OS X 8.5.0. There is a simple correction to
this problem that involves using autoconf tests for the
appropriateness of these options before adding them to
the BASECFLAGS environment variable. In particular the
following works:
Replace the line
BASECFLAGS="$BASECFLAGS -Wno-long-double
-no-cpp-precomp -mno-fused-madd"
at or near line 3165 under the Darwin case in configure.in
with the following test
AC_LANG_SAVE
AC_LANG_C
ac_save_cc="$CC"
for arg in -Wno-long-double -no-cpp-precomp
-mno-fused-madd ; do
CC="$ac_save_cc $arg"
AC_COMPILE_IFELSE([
AC_LANG_SOURCE([[
#include <stdlib.h>
#include <stdio.h>
int main(int argc,char**argv)
{
return 0;
}
]])],[BASECFLAGS="$BASECFLAGS $arg"],[])
done
CC="$ac_save_cc"
AC_LANG_RESTORE
in other words test to see if the option works with the
chosen compiler before adding it blindly to BASECFLAGS.
I am attaching this version of configure.in for your
convenience. I tested my build of Python-2.4.2 on both
Linux and Darwin using the apple version of gcc 3.3 as
well as Gnu versions gcc 4.0.2 and 4.1 that I built
from source. The build and install worked properly and
the python executable was runable in all cases. I did
not perform more extensive regression tests, but I
believe this change has no effect for compilations
using previously support configurations, and only
applies for new currently unsupported compilers.
|
|||
| msg63535 - (view) | Author: Ralf Schmitt (schmir) | Date: 2008年03月14日 19:19 | |
This should be closed: from http://python.org/download/releases/2.4.5/: "Since the release candidate, we received various reports that the this release may fail to build on current operating systems, in particular on OS X. We have made no attempt to fix these problems..." |
|||
| msg63539 - (view) | Author: Jeffrey Yasskin (jyasskin) * (Python committer) | Date: 2008年03月14日 22:38 | |
I think this is still a problem at head, so it's not covered by the comment about the bugfix releases. But there is another issue covering the same thing... Since that one also has a patch and is a little newer, I'll point this one over there. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:56:15 | admin | set | github: 43038 |
| 2008年03月14日 22:38:29 | jyasskin | set | status: open -> closed resolution: duplicate superseder: Make python build with gcc-4.2 on OS X 10.4.9 messages: + msg63539 |
| 2008年03月14日 19:19:12 | schmir | set | nosy:
+ schmir messages: + msg63535 |
| 2007年08月25日 04:13:33 | jyasskin | set | nosy: + jyasskin |
| 2006年03月15日 23:36:35 | johnwgrove | create | |