[Python-bugs-list] [ python-Bugs-434547 ] Problems with C++ ext. on Tru64
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 19 Jun 2001 11:18:47 -0700
Bugs item #434547, was updated on 2001-06-19 11:18
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434547&group_id=5470
Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems with C++ ext. on Tru64
Initial Comment:
{ I post this letter to comp.lang.python for
discussion, python sourceforge bugtracker to
make sure someone reads it and
omniorb@uk.research.att.com
as important appendix to the letter about compiling
omniORB on Tru64 }
I am currently trying to compile
Python/OmniORB/OmniORBpython suite on Tru64 Unix (the
new name for Digital Unix/OSF) with DEC CXX 6.2. For
the
longer story search for my next post, but I have some
important observations about Python. Are they bugs?
Anyone skilled to check it further is welcome. In case
I
should post this somewhere else, please let me know.
The tests described below used Python 2.1. The problem
which forced me to perform this analysis happened
during
compilation of omniORB 3.0.3.
I start from the less important things going to the
more important.
1) While compiling Python with DEC CXX (below you will
find why I did it), I got the error message (on
Include/structmember.h) about incorrect usage of
language extension (probably they in some situations
use
'readonly' in the way similar to 'const'). I have not
diagnosed it in the great detail (seems that compiler
options and pragmas set by python makefiles influence
the situation somehow) but changing readonly to - say -
read_only should not spoil anything and will help. I
worked around the problemy by using
cxx -Dreadonly=_readonly
as the compiler name.
2) In contrary to most configure scripts, Python
configure script ignores environment variable CC. The
problem is in case switch checking wheter --with-gcc or
--without-gcc is specified:
if test "${with_gcc+set}" = set; then
(....)
else
case $ac_sys_system in
OSF1) CC=cc
without_gcc=;;
(...)
To compile python with cxx I manually edited the line
above but I think compiling python with compiler
different than cc and gcc should be possible in the
natural way. In case people dislike CC checking,
maybe --with-cc=<...> could be done?
3) So, let's tell why I needed to compile python with
DEC CXX. While using 'default' (compiled with cc)
python, I was unable to use python extension modules
written in C++ (I got the problem while trying to
compile and use _omniidl module from omniORB but seems
it would be the same for others):
- the '_omniidlmodule.so' file links correctly and is
correct
- attempts to import it results in
python -c 'import _omniidl'
Traceback (innermost last):
File "<string>", line 1, in ?
ImportError: dlopen: Unresolved symbols
The problem is caused by the lack of symbols from
libcxx.so (C++ compiler shared library). I am not
expert
regarding dlopen but seems that python, while loading
the module, does not load shared libraries the module
depends on (at least on Tru64). After I recompiled
python with cxx (mainly to get the python executable
linked permanently with libcxx.so so this library is
present while my module is being imported) the problem
disappeared and the module imported and worked
correctly.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434547&group_id=5470