Problems with omniORB and omniORBpy on Tru64 - with solution

[Marcin Kasperski]

{ I post this letter to comp.lang.python as 
  some people could be interested in building
  omniORBPython on Tru64 and to 
  omniorb at uk.research.att.com as bugreport. }

I am currently trying to compile
Python/OmniORB/OmniORBpython suite on Tru64 Unix (new
name for Digital Unix/OSF) with DEC CXX 6.2. I got some
problems and solved it, below there are some interesting
details.

The tests described below used Python 2.1 and 
omniORB 3.0.3.

1) There is one major flaw in omniORB makefiles for
Tru64: in many places they use 'ld' to link C++ code.
This leads to things like 

ld:
Warning: Unresolved:
__nwa__XUl
__dla__XPv
__stdnw__XUl
__vtbl_3std9type_info__3std
__vec_new_eh
__vec_delete

(the symbols change from place to place).

The 'so' files are created but are useless (can not be 
run with or - in case of python extension modules
- can not be imported - due to unresolved symbols).

To correct the problem I edited the following files:
   omni/mk/platforms/alpha_osf1_5.0.mk
      (under 'define MakeCXXSharedLibrary')
   omni/src/tool/omniidl/cxx/dir.mk
      (under 'OSF1')
   omni/src/lib/omniORB2/orbcore/sharedlib/dir.mk 
      (under 'OSF1')
   omni/src/lib/omniORB2/dynamic/sharedlib/dir.mk 
      (under 'OSF1')
   omni/src/lib/omniORB2/orbcore/gatekeepers/tcpwrapper/sharedlib/dir.mk
      (under 'OSF1')
and (the file from omniORBpy):
   omni/src/lib/omniORBpy/modules/dir.mk 
      (under 'OSF1').

   In all those placed I:
   - changed 'ld' to 'cxx'
   - removed '-lcxxstd -lcxx -lexc -lots -lc' (no longer needed)

   For instance, the last of the files mentioned contain after
   my change (look forward for PYLIBDIR and -lm which were added
   by me too):
$(lib): $(OBJS)
	(set -x; \
         $(RM) $@; \
         cxx -shared -soname $(soname) -set_version $(soname) -o $@
$(IMPORT_LIBRARY_FLAGS) \
         $(filter-out $(LibSuffixPattern),$^) $(OMNIORB_LIB_NODYN)  \
	 -L$(PYLIBDIR) -l$(PYLIBFILE) \
	 -lm \
        )

2) Lack of linkage with Python 

{The thing which proves nobody attempted the compilation ;-)}
While compiling in directories 
  omni/src/tool/omniidl/cxx/
and (the dir from omniORBpy):
   omni/src/lib/omniORBpy/modules/
I got 

Warning: Unresolved:
PyType_Type
_Py_NoneStruct
PyTuple_Type
PyList_Type
(... many more ...)

The reason is simple: rules for Tru64 (and maybe other
platforms too) does not link with libpython! To correct
it I edited the files
   omni/src/tool/omniidl/cxx/dir.mk
and
   omni/src/lib/omniORBpy/modules/dir.mk
and in both cases:
a) I added the lines
  PYLIBDIR  := $(PYPREFIX)/lib/python$(PYVERSION)/config
  PYLIBFILE := python$(PYVERSION)
within 'ifdef UnixPlatform', just below PYINCFILE := ...
b) I added
  -L$(PYLIBDIR) -l$(PYLIBFILE) -lm
to the linking rule under OSF1 (look 20 lines up to see
the example). -lm seems to be required by python
libraries, without it I got unresolved frexp, modf, fabs
etc.

3) DEC CXX complained for incorrect syntax on 
   #if NeedVarargsPrototypes
(I observed numerous warning and got errors in 
 omni/src/tool/omkdepend/main.c). To correct, 
I grepped for this and changed to
   #ifdef NeedVarargsPrototypes
and got correct compilation. 

Instead one probably could edit omni/src/tool/omkdepend/def.h
and change from 
  #if defined(__osf1__)
  #define NeedVarargsPrototypes
  #endif
to
  #if defined(__osf1__)
  #define NeedVarargsPrototypes 1
  #endif
but the first solution seems to me to be better for
other platforms.

4) This problem is probably independent from omniORB but
very important. The default compilation results in

    Traceback (innermost last):
       File "<string>", line 1, in ?
    ImportError: dlopen: Unresolved symbols

during the first call to omniidl. The reason? There are
no symbols from libcxx.so. It is probably some
'dynaload' python problem. To correct it I recompiled
python itself with cxx instead of cc. The very details 
I describe in the separate letter which should come
together with this one.

5) After everything described above I got running
omniORB and omniORBpython on Tru64. At least the first
samples I tried worked as expected.