[Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 10 Aug 2001 01:58:35 -0700
Bugs item #438786, was opened at 2001-07-05 07:54
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470
Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Martin v. Löwis (loewis)
Summary: CVS 2.1.1c1 broken on osf1V4
Initial Comment:
As of right now, the CVS branch for the 2.1 bugfix
release cannot import the math module on my Digital
Unix platform.
ImportError: Unresolved symbol in
/tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so:
__eprintf
uname is
OSF1 surya V4.0 878 alpha
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2001-08-10 01:58
Message:
Logged In: YES
user_id=21627
Ok, I have committed your setup.py patch as 1.47.
I still cannot see the problem solved with the
Makefile.pre.in. If I set CC to 'foo' and invoke make,
setup.py will still use 'gcc', not 'foo'. The reason is that
make passes all variables that where in the original
environment to subprocesses; if they were overwritten in the
Makefile, it will pass the new values (unless -e was
specified).
----------------------------------------------------------------------
Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-30 11:38
Message:
Logged In: YES
user_id=11365
Thanks for your work on this. I'll try and explain about
setup.py etc.
If you look in
distutils.sysconfig.customize_compiler(compiler)
you will see that the command line for compiling shared
libraries is built up from Makefile variables like so:
$(CC) $(OPT) $(CCSHARED)
which is consistent with the traditional operation of the
python Makefile.
The problem with setup.py is that it does not recognize
the importance of the $(OPT) variable. Before the
extensions are built it decides to recreate the compilation
command line using the current environment variables (I
doubt this is a worthwhile thing to do, but anyway...)
and if it finds $CC in the environment it effectively
defines the command line to be
$(CC) $(CCSHARED)
i.e. $(OPT) has disappeared, and the CC variable is expected
to take on its role.
This is inconsistent with
1) The way distutils normally treats $(CC)
2) The way the Makefile uses $(CC)
3) The way make interprets $CC in the environment
4) The way configure interprets $CC in the environment.
Now until fairly recently there was no setup.py in the
python build process. If you set CC=gcc in the environment
it would be interpreted consistently as in 2/3/4 above,
specifically, *not* implying that you wished not to use the
$(OPT) variable in the Makefile.
Ok, so let's assume that I didn't know that this was a bad
idea and kept doing it with the new python build. At the
last step of building the shared modules, the value of
$(OPT) is discarded. This is probably something like
OPT = -g -O3 -Wall -Wstrict-prototypes
so the shared modules are built without optimisation or
compiler warnings turned on. Ok, I admit this doesn't break
the build. But it could harm the performance of one's
python install noticeably.
So, my patch addresses this in a minimal way. The
optimization flags OPT from distutils.sysconfig are retained
in the new commandline. That's all.
This is really just a slight generalization of the patch
attached to #437487 which made sure that $(CCSHARED) was
retained in the commandline... omitting it broke the build
very badly in some cases.
Finally, the patch I was thinking about to Makefile.pre.in
addresses this comment in setup.py
# When you run "make CC=altcc" or something similar, you
# really want those environment variables passed into the
# setup.py phase. Here's a small set of useful ones.
The problem is that just because a variable is in the
environment does *not* mean that it was passed as an
argument to make. It is unfortunate that that's the way
make passes on variables, and it can't be disambiguated.
Make itself of course *doesn't* accept CC from the
environment since that is overridden by an assigment in the
Makefile. So the make part of the build and the setup.py
part of the build become inconsistent.
This caused the original problem on OSF1V4: configure looked
at $CC and decided it was to be ignored. Setup.py had no
clue that this decision had been made, and reinstated it.
The result was that the dynamic modules were linked with
the wrong libraries.
The fix I thought about was this: when invoking setup.py
from the Makefile, explicitly pass CC (and LDSHARED which is
treated the same) in its environment.
My second attempt is attached here - it quotes the variables
which is needed of course...
What would be better is if you could give a commandline
argument to setup.py. The help says that there is a
--compiler (-c) option to the build command.
That is not currently helpful though. I tried
./python setup.py build -c gcc
and saw
raise DistutilsPlatformError, msg
distutils.errors.DistutilsPlatformError: don't know how to
compile C/C++ code on platform 'posix' with 'gcc' compiler
which is unfortunate...
So that about covers it, I hope.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-07-25 00:48
Message:
Logged In: YES
user_id=21627
osf.patch was committed as 1.235. As for the changes to
setup.py and Makefile.pre.in: I cannot understand what
problem they solve. Please demonstrate the bug that is fixed
with these changes in more detail (i.e. what is the setting
of your environment variables, and what unexpected results
do you get without these changes).
----------------------------------------------------------------------
Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 14:39
Message:
Logged In: YES
user_id=11365
I tried testing that patch and it sucked.
I'll try again.
----------------------------------------------------------------------
Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:06
Message:
Logged In: YES
user_id=11365
Doh! Now it's uploaded. Sorry for the extra traffic.
----------------------------------------------------------------------
Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:05
Message:
Logged In: YES
user_id=11365
Next patch uploaded.
----------------------------------------------------------------------
Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:04
Message:
Logged In: YES
user_id=11365
Yes, the patch works and make test fails only on
test_format, I believe this is a known platform C library
bug.
I have attached a patch for the setup.py in python/dist/src.
It touches code which is supposed to allow variables set on
the make commandline to have effect. I see two issues with
it.
One, it effectively replaces CC and OPT from the Makefile
with just CC. This is inconsistent with the behaviour of
the Makefile and configure. My setup.patch addresses this.
Two, it doesn't really do what it says, because the variable
it picks up from the environment can has not necessarily got
there through a commandline argument to make. This only
becomes a problem when configure decides to ignore an
environment variable, as was the case on OSF. Martin's
patch stops this from happening on OSF, but the code is
still fragile.
Here's an idea: make should always export its value of CC
into the environment of subprocesses. Using Gnu make I'd do
this with an 'export' directive. I'll next send a patch to
Makefile.pre.in which should do the job portably but it
isn't especially pretty.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-07-24 00:11
Message:
Logged In: YES
user_id=21627
Gregory, can you please try the attached patch, and report
whether it changes anything?
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-19 13:33
Message:
Logged In: YES
user_id=6380
I don't recall why that was. It was 6 years ago! Quite
possibly things have changed; the OSF in use now is probably
quite different than the one then.
So, Martin, try to back out the change and see if this
doesn't break other things.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-07-19 12:38
Message:
Logged In: YES
user_id=21627
This seems to originate fromt the fragment
OSF1) CC=cc
without_gcc=;;
which was introduced in configure.in 1.23, with the comment
on osf/1, never use gcc
Therefore, I'm assigning it to Guido. My proposal is to
close this as "won't fix" - if setting CC doesn't work,
just don't do that.
Alternatively, if nobody can remember why gcc should not
be used on OSF/1, it might be reasonable to back-out this
change.
----------------------------------------------------------------------
Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-19 12:12
Message:
Logged In: YES
user_id=11365
I just checked out the 2.1.1 branch again and
it still seems to be broken. After a fresh config with $CC
set to gcc in the environment, the Makefile contains
CC= cc
OPT= -O -Olimit 1500
CCSHARED=
so it looks like configure has decided to use cc and
chosen flags for that compiler.
Then, the actual build command lines look like
gcc -I.
-I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include
-I/usr/local/include -IInclude/ -c
/tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o
i.e. just "gcc" instead of "cc -O -Olimit 1500"
so it looks like the environment variable gets pulled in
only at the last moment and replaces $(CC), $(OPT) and
possibly $(CCSHARED), thereby throwing away the work done by
configure.
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2001-07-19 02:59
Message:
Logged In: YES
user_id=34209
Gregory, did you get a chance to test the patch attached to
bug #437487, or the 2.1.1 CVS tree ? I'd like to know if
this is fixed in 2.1.1.
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2001-07-16 08:56
Message:
Logged In: YES
user_id=34209
Ah, yes, that sounds very plausible. The fix for that
problem, which was checked in on the trunk, will be in
Python 2.1.1-final as well. The Solaris bugreport has a
patch attached to it; could you test it to see if it solves
your 2.1.1c1 problem ?
----------------------------------------------------------------------
Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-09 08:48
Message:
Logged In: YES
user_id=11365
The problem goes away if I clear $CC instead of having it
set to gcc. There's a similar problem on Solaris reported
recently.
I think the configure script should try to spot this sort of
thing,
but I suppose that's an Autoconf feature request, not a
python bug...
Thanks.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-07-08 14:06
Message:
Logged In: YES
user_id=21627
This sounds like a bug in your compiler installation.
__eprintf is typically defined in libgcc.a; make sure you
use a consistent compiler capable of building binaries for
your system throughout the build process.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470