[Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 24 Jul 2001 11:05:09 -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: 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