Nontrivia: compilation/linkage problems with Python on Tru64 troublesome for omniORB

[Marcin Kasperski]

{ I post this letter to comp.lang.python for 
  discussion, python sourceforge bugtracker to
  make sure someone reads it and omniorb at 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.

--
http://www.mk.w.pl /
 Marcin.Kasperski | Internetowy arkusz pracy (timesheet):             
   @softax.com.pl |   http://www.mk.w.pl/programy/timesheet           
     @bigfoot.com  \