[Python-bugs-list] [ python-Bugs-437487 ] 2.1 build on Solaris fails if CC is set
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 13 Jul 2001 03:00:53 -0700
Bugs item #437487, was opened at 2001-06-29 15:42
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470
Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: 2.1 build on Solaris fails if CC is set
Initial Comment:
If you have CC set to "gcc", then the "setup.py" script
compiles
the extensions incorrectly (in particular, the "-fPIC"
on the compile is
not used):
...
PYTHONPATH= ./python ./setup.py build
running build
running build_ext
building 'struct' extension
creating build
creating build/temp.solaris-2.7-sun4u-2.1
gcc -I. -I/extra/Python-2.1/./Include
-I/usr/local/include -IInclude/ -c
/extra/Python-2.1/Modules/structmodule.c -o
build/temp.solaris-2.7-sun4u-2.1/structmodule.o
creating build/lib.solaris-2.7-sun4u-2.1
gcc -shared
build/temp.solaris-2.7-sun4u-2.1/structmodule.o
-L/usr/local/lib -o
build/lib.solaris-2.7-sun4u-2.1/struct.so
Text relocation remains
referenced
against symbol offset in file
<unknown> 0x2094
build/temp.solaris-2.7-sun4u-2.1/structmodule.o
<unknown> 0x200c
build/temp.solaris-2.7-sun4u-2.1/structmodule.o
<unknown> 0x3398
build/temp.solaris-2.7-sun4u-2.1/structmodule.o
<unknown> 0x2098
build/temp.solaris-2.7-sun4u-2.1/structmodule.o
<unknown> 0x2070
build/temp.solaris-2.7-sun4u-2.1/structmodule.o
<unknown> 0x206c
....
If you want to compile code configured via "configure"
with the "gcc"
compiler and you have both the "gcc" and the Sun C
compiler installed
on your system, then you need to have the environment
variable
"CC" set to "gcc":
CC=gcc
So people (like myself) have "CC=gcc" in their .profile
or equivalent
in .login, and have had that for years without thinking
about it.
If you don't have "CC=gcc" set in your environment,
then things
work fine:
...
PYTHONPATH= ./python ./setup.py build
running build
running build_ext
building 'struct' extension
creating build
creating build/temp.solaris-2.7-sun4u-2.1
gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I.
-I/home/tflagg/projects/python/2.1sunos/Python-2.1/./Include
-I/usr/local/include -IInclude/ -c
/home/tflagg/projects/python/2.1sunos/Python-2.1/Modules/structmodule.c
-o build/temp.solaris-2.7-sun4u-2.1/structmodule.o
(In particular, the "-fPIC" flag needs to be there as
shown above.)
The problem lines in "setup.py" are:
112 # When you run "make CC=altcc" or
something similar, you really want
113 # those environment variables passed
into the setup.py phase. Here's
114 # a small set of useful ones.
115 compiler = os.environ.get('CC')
<----------
116 linker_so = os.environ.get('LDSHARED')
117 args = {}
118 # unfortunately, distutils doesn't let
us provide separate C and C++
119 # compilers
120 if compiler is not None:
<---------------
121 args['compiler_so'] = compiler
<---------
It's true the user may want to set
site-specific/user-specific
compiler options. However, if "CC" is only "gcc" then
the user is
trying to communicate:
- Use "gcc" rather than Sun's C compiler
They are NOT trying to communicate:
- Do not use any of the compiler flags for compiling
shared objects.
The reason this bug Solaris-specific is because
Solaris
installations are the most likely to have a non-gcc
compiler installed, requiring the "CC=gcc" environment
variable set.
----------------------------------------------------------------------
>Comment By: Thomas Wouters (twouters)
Date: 2001-07-13 03:00
Message:
Logged In: YES
user_id=34209
This works, but I'm not sure if it has any effect... the
shared modules were compiling fine before it, except for a
few that referenced libraries that itself referenced other
shared libraries (I suspect) -- like the readline and socket
(with SSL) modules. Disabling SSL makes the socketmodule
work okay. I'm not sure what kind of effect this has on
applications that embed Python, or that extend Python and
want to link to one or more externals libraries... :-P
Could it be that distutils is picking up static libraries,
and linking them the 'wrong' way ('-llibrary' instead of
'/path/to/library.a') ?
Note that this Solaris 7 machine is not in real use, and I
*might* be running into installation issues... but I don't
think so, I thought a colleague had compiled things on it
before.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2001-07-12 09:16
Message:
Logged In: YES
user_id=11375
The dangers of multiple machines... try this patch,
instead.
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2001-07-12 09:02
Message:
Logged In: YES
user_id=34209
AMK, I'm running into this problem now, while testing on
Solaris 2.7. However, the patch attached here, seems to be
the wrong one (it adds checking for sys/poll.h, looks like.)
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2001-07-11 13:09
Message:
Logged In: YES
user_id=11375
Proposed patch attached; if the original poster is
monitoring this bug, please try it and let me know if it
helps. Otherwise, I'll check it in in a few days.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470