[omniORB] build problems on solaris 2.6

[Duncan Grisby]

On Monday 9 October, "McConnell, Edmund" wrote:

> i'm trying to build a system with python1.6, omniORB3.0.2 and omniORBpy1.2
> on solaris 2.6 using Sunpro C++ 4.2-patch-104631-07.
>  
> i'm using omniORB config file $TOP/mk/platforms/sun4_sosV_5.6.mk.

Unfortunately, we don't have any Solaris 2.6 machines here, only 2.5
and 2.7. We have the 4.2 compiler on 2.5, and it works fine there. I'm
not sure if the compiler is patched at all. CC -V just says

  CC: WorkShop Compilers 4.2 30 Oct 1996 C++ 4.2

> + CC -G -o _omnipymodule.so.0.5 -h _omnipymodule.so.0
> -L../../../../lib/sun4_sosV_5.6 -R ../../../../lib/sun4_sosV_5.6
> omni30/omnipy.o omni30/pyORBFunc.o omni30/pyPOAFunc.o
> omni30/pyPOAManagerFunc.o omni30/pyObjectRef.o omni30/pyCallDescriptor.o
> omni30/pyServant.o common/pyExceptions.o common/pyMarshal.o
> common/pyTypeCode.o common/pyThreadCache.o common/pyomniFunc.o -lomniORB3
> -ltcpwrapGK -lomnithread -lpthread -lposix4 -mt -lsocket -lnsl -lC 
>  
> ld: fatal: symbol `Strand::isOutgoing(void)' is multiply defined:
>  (file omni30/omnipy.o and file omni30/pyORBFunc.o);
> ld: fatal: symbol `operator <<=(omniObjKey&, NetBufferedStream&)' is
> multiply defined:
>  (file omni30/omnipy.o and file omni30/pyORBFunc.o);

That's very odd. All of the functions it is complaining about are
inline functions in omniORB headers. I don't know why it thinks it
matters that they are multiply defined. Please can you send the
compile line for one of the .o files (omni30/omnipy.o for example) to
see if anything looks dodgy about it.

Are you able to compile the omniORB example programs in src/examples ?

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --