Problems with omniORB and omniORBpy on Tru64 - with solution

Marcin Kasperski Marcin.Kasperski at
Tue Jun 19 20:13:59 CEST 2001

{ I post this letter to comp.lang.python as 
  some people could be interested in building
  omniORBPython on Tru64 and to 
  omniorb at 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

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 

Warning: Unresolved:

(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:
      (under 'define MakeCXXSharedLibrary')
      (under 'OSF1')
      (under 'OSF1')
      (under 'OSF1')
      (under 'OSF1')
and (the file from omniORBpy):
      (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 $@
         $(filter-out $(LibSuffixPattern),$^) $(OMNIORB_LIB_NODYN)  \
	 -lm \

2) Lack of linkage with Python 

{The thing which proves nobody attempted the compilation ;-)}
While compiling in directories 
and (the dir from omniORBpy):
I got 

Warning: Unresolved:
(... 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
and in both cases:
a) I added the lines
  PYLIBDIR  := $(PYPREFIX)/lib/python$(PYVERSION)/config
within 'ifdef UnixPlatform', just below PYINCFILE := ...
b) I added
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

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
  #if defined(__osf1__)
  #define NeedVarargsPrototypes 1
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 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.

More information about the Python-list mailing list