[omniORB] 3.0.4 - HPUX 10.20 & GCC

[Brenneis, Steve]

I don't think you will have any problems using omniORB built with aCC and cc
in conjunction with your gcc built applications. The only linkage will be at
the shared library level and the compiler should make no difference as long
as they both use the right architecture. On 10.20 you should only have one
choice.

I haven't followed up on the recursive COPTION, but I'm curious why that
would be a problem for gcc and not aCC since it is occurring in the make
system. What version of GNU make are you using? Also, you usually have to
fiddle with your path settings since HP puts their bundled make in /usr/bin
and GNU make defaults to /usr/local/bin. Most people either set their path
environment or set an alias for make to get around this.

As a fallback, I might suggest you use the mini-python distribution from
omni that is described in the README.hpux. You will have to unset your
PYTHONPATH to use it, but it works very well for us under HP-UX 11.0 on
N-class servers.

I hope this is helpful.

Steve Brenneis

-----Original Message-----
From: Kevin Williams [mailto:zak@quantum.supernova.org]
Sent: Thursday, November 29, 2001 2:11 PM
To: Brenneis, Steve
Cc: 'omniorb-list@uk.research.att.com'
Subject: RE: [omniORB] 3.0.4 - HPUX 10.20 & GCC


I haven't renamed any directories.  I haven't even been able to build the
ORB yet.  Neither _omniidlmodule.sl or .so exist in my OmniORB directory
anywhere.  I'm assuming that 'make export' should be creating them, but it
doesn't appear to be working.  When I go through the directories looking
for a makefile that should build it, I'm having no luck.  Every makefile
that I suspect (src/tool/omniidl/GNUmakefile for instance) gives me
"Nothing to be done for 'all'".

Since I had to modify the mk/platforms/hppa_hpux_10.20.mk to not have the
recursive COPTIONS mention, I'm afraid I may have screwed something
up.  Perhaps the problem only occurs when trying to use GCC to build
OmniORB on HP?  I'd just use the native compiler, but the programs I need
to link to the ORB are all built with GCC.  Am I not correct in assuming
that an OmniORB built with the native compiler won't link with a program
built with GCC?

We actually are currently using OmniORB 2.7.1 on HP without any issues,
but I was not here 1.5 years ago when it was built, so I'm not sure how it
was done.  I'm hoping to get the ORB built for HPUX soon - all of the
porting work from 2.7.1 to 3.0.4 is done on all of the other platforms I
need it on! <smile>

Thanks,
-Kevin

On Thu, 29 Nov 2001, Brenneis, Steve wrote:

> Well, first, the shared module should be _omniidlmodule.sl on HP instead
of
> _omniidlmodule.so, but I'm not sure why it doesn't show up in your omniORB
> library directory. If you set the PYTHONPATH variable, then the library
> should be there if it is not in your omniORB tree. Did you perhaps rename
> the omni root directory after building it?
> 
> Steve Brenneis
> WebAXE Middleware Lead Developer
> AT&T Wireless Services
> Desk (336) 286-1783
> Cell (336) 456-3290
> FAX (336) 286-1880
> 
> 
> -----Original Message-----
> From: Kevin Williams [mailto:zak@supernova.org]
> Sent: Thursday, November 29, 2001 11:22 AM
> Subject: [omniORB] 3.0.4 - HPUX 10.20 & GCC
> 
> 
> First, yes...  I have built Python 2.1 using the HPUX native compiler (not

> gcc) and followed the instructions in the README.hpux11 file to compile
> python.o using aCC and to use aCC for linking.  Python appears to work
> fine.
> 
> Upon editing mk/platforms/hppa_hpux_10.20.mk to use GCC instead of aCC, I
> noticed what appears to be a recursive variable definition - COPTIONS is
> assigned the value of $(COPTIONS).  I removed the recursive variable and
> attempted a make export.  Here is the error I received:
> 
>  omniidl: ERROR!
> 
>  omniidl: Could not open IDL compiler module _omniidlmodule.so
>  omniidl: Please make sure it is in directory
>  /disk1/kevin/omniOrb-3.0.4/lib/hppa_hpux_10.20
>  omniidl: (or set the PYTHONPATH environment variable)
> 
>  omniidl: (The error was `No module named _omniidl')
> 
> Here are the contents of that directory...
> 
> -rwxr-xr-x 1 kevin   users     42928 Nov 26 13:20 libomnithread.a
> -rwxr-xr-x 1 kevin   users    200958 Nov 26 13:19 omnicpp
> 
> I'll also mention, my PYTHONPATH variable is set to
> /usr/local/lib/python2.1 (the default install path for Python 2.1
> and a path that worked fine for my Solaris build).  So, aparently I am
> missing the _omniidlmodule.so library for some reason.  The problem is, I
> can't figure out why and I can't figure out how to get it! <smile>
> 
> Any help would be appreciated.
> --Kevin
>