[omniORB] Successful HP-UX 11 build of omniORB-4.0.2 (sort of).

Tingle, Alex Alex.Tingle at bronermetals.com
Thu Oct 2 18:57:18 BST 2003


Summary:

To get omniORB-4.0.2 to compile and run on HP-UX 11, upgrade to a new
version of python and change the Compiler_aCC section in
build/mk/beforeauto.mk to read:

	ifdef Compiler_aCC
	CXXDEBUGFLAGS     = -O
	CXXOPTIONS   	 += -w +inst_v +DAportable -mt
	CXXLINKOPTIONS   += -Wl,+s
	CDEBUGFLAGS       = -O
	COPTIONS	  = -w -Aa -D_HPUX_SOURCE +DAportable
	CLINKOPTIONS      = -Wl,+s

	SHAREDLIB_CPPFLAGS += +Z
	SharedLibraryPlatformLinkFlagsTemplate = -b -Wl,+h$$soname
-Wl,+s \
	 -lstd_v2 -lCsup_v2 -lC # <--- Only _omniidl requires these
libs, they break
	endif                   #      other shared code.


Full story. Sorry this is so 'chatty', but I wrote it as I went along:

>>> make[3]: *** [omniORB4/Naming.hh] Bus error (core dumped)

OK, I got past this point by upgrading my python installation to Python
2.2.3. I'm guessing that the latest changes have broken backwards
compatability with python 1.5.2 which I had been using.

Sadly, that's not the end of the story. With the newer python, omniORB
builds and installs, but it still doesn't run. For example, 'nameclt
list' gives the following:

	omniORB: Warning: the config file is in the old pre-omniORB4
format.
	aCC runtime: ERROR: Unexpected use of shared libraries
	aCC runtime: ERROR: Read aCC manpage, +A option
	/usr/lib/libnss_dns.1

Now, this is one of the most helpful error messages I've ever seen the
HP-UX produce. Here's a fragment of the file build/mk/beforeauto.mk that
./configure generated for me:

	ifdef Compiler_aCC
	CXXDEBUGFLAGS     = -O
	CXXOPTIONS   	 += -w +inst_v +DAportable \
		      -D_THREAD_SAFE \
		      -DRWSTD_MULTI_THREAD \
		      -DRW_MULTI_THREAD 
	CXXLINKOPTIONS   += +A -Wl,+s
	CDEBUGFLAGS       = -O
	COPTIONS	  = -w -Aa -D_HPUX_SOURCE +DAportable
	CLINKOPTIONS      = -noshared -Wl,+s

	SHAREDLIB_CPPFLAGS += +Z
	SharedLibraryPlatformLinkFlagsTemplate = -b -Wl,+h$$soname
-Wl,+s -lstd_v2 -lCsup_v2 -lC
	endif

CXXLINKOPTIONS is set wrong. aCC +A is incompatible with ld +s. Here are
the relevant man page entries:

	man aCC

	+A Cause the linker ld(1) to use only archive libraries
	   for all occurrences of the -l option.  Also inform the
	   C++ run-time environment that no shared libraries will
	   be used by the program.
	   NOTE: Cannot be used when calling shl_load(3) directly
	   or indirectly.  See HP aC++ Online Programmer's Guide,
	   HP-UX Linker and Libraries Online User's Guide and
	   setlocale(3) for more information.


	man ld

	+s Indicates that at run-time, the shared library
	   loader can use the environment variable SHLIB_PATH
	   and LD_LIBRARY_PATH (64-bit only) to locate shared
	   libraries needed by the executable output file
	   that were specified with either the -l or -l:
	   option. The environment variables should be set to
	   a colon-separated list of directories. If both +s
	   and +b are used, their relative order on the
	   command line indicates which path list will be
	   searched first (see the +b option).

Fixing this doesn't help much though. 'nameclt list' now just coredumps
with a signal 11! So, I'll try and fix any other obvious problems.

CLINKOPTIONS is set incorrectly. The -noshared option is incompatible
with the +DAportable architecture:

	man cc

	-noshared Creates statically bound executables.  This option is
		  available with option +DA2.0W only.  See -dynamic for
		  dynamically bound executables.  The default behavior
is
		  dynamic. 

CXXOPTIONS is a little suspect too. The multi-thread flags are not
supposed to be set explicitly, they should be turned on with the -mt
option (which has other effects too, see:
http://docs.hp.com/hpux/onlinedocs/2213/options.htm#option-mt). So I've
replaced '-DRWSTD_MULTI_THREAD -DRW_MULTI_THREAD' with '-mt'. The flag
'_THREAD_SAFE' is never referred to by the omniORB code, so I've removed
that as well.

And the result? 'nameclt list' STILL coredumps with a signal 11!

Final change - (this actually makes it work)...
SharedLibraryPlatformLinkFlagsTemplate explicitly links in some runtime
libraries (-lstd_v2 -lCsup_v2 -lC). This can't be right can it? OK, so
remove them.

AND IT WORKS!!!

...ish. I made all of the above changes whilst rebuilding with 'make
clean; make'. 'make veryclean; make' now fails, with:

	make[3]: Entering directory
`/users1/alext/src/omniORB-4.0.2/build/src/lib/omniORB'
	/users1/alext/32bit/bin/python
../../../../bin/scripts/distdate.py \
	 <../../../../update.log >omniORB4/distdate.hh
	../../../bin/omniidl -bcxx -Wba -p../../../../src/lib/omniORB
-Wbdebug \
	 -v -ComniORB4 ../../../../idl/Naming.idl

	omniidl: ERROR!

	omniidl: Could not open IDL compiler module _omniidlmodule.so
	omniidl: Please make sure it is in directory
/users1/alext/src/omniORB-4.0.2/build/lib
	omniidl: (or set the PYTHONPATH environment variable)

	omniidl: (The error was \
	 'Failed to load
/users1/alext/src/omniORB-4.0.2/build/lib/_omniidlmodule.sl')

So, although the changes above seem to work for omniORB libraries and
executables, the omniidl python module no longer wants to load. I feel
like I'm going round in circles!

But the solution to this is simply to undo the last change I made.
Reintroduce the libraries '-lstd_v2 -lCsup_v2 -lC' to the
SharedLibraryPlatformLinkFlagsTemplate macro, and the python module
builds and loads successfully.

Anyone care to try and resolve this?

regards,

-Alex

--

> -----Original Message-----
> From: Christophe Goua [mailto:cgoua at bibliomondo.com]
> Sent: 15 September 2003 18:32
> To: Omniorb-List at Omniorb-Support. Com
> Subject: RE: [omniORB] Re: HP-UX 11 build problem
> 
> 
> I've been trying to deal with these issues for a while now, 
> but with no
> result...
> I too would be glad to hear if someone has succesfully built 
> omniORB 4.x on
> HP-UX...
> 
> Christophe Goua
> BiblioMondo Inc.
> Montreal, Canada
> 
> > -----Original Message-----
> > From: omniorb-list-bounces at omniorb-support.com
> > [mailto:omniorb-list-bounces at omniorb-support.com]On Behalf Of Pierre
> > Pacchioni
> > Sent: 15-Sep-2003 12:27
> > To: omniorb-list at omniorb-support.com
> > Subject: RE: [omniORB] Re: HP-UX 11 build problem
> >
> >
> > >../../../bin/omniidl -bcxx -Wba -p../../../../src/lib/omniORB
> > -Wbdebug -v -
> > C
> > >omniORB4 ../../../../idl/Naming.idl
> > >omniidl: Importing back-end 'cxx'
> > >omniidl: 'cxx' imported from
> > >'../../../../src/lib/omniORB/omniidl_be/cxx/__init__.py'
> > >omniidl: Preprocessing '../../../../idl/Naming.idl' with
> > >'/amd_tmp/needle-8/users0/cstaff/tpl/SRC/omniORB-4.0.1/omni/build
> /lib/omnic
> > p
> > >p
> > >-lang-c++ -undef -D__OMNIIDL__=0x2420 -D__OMNIIDL_CXX__
> > >"../../../../idl/Naming.idl"'
> > >omniidl: Running front end
> > >omniidl: Running back-end 'cxx'
> > >make[3]: *** [omniORB4/Naming.hh] Bus error (core dumped)
> > >make[3]: *** Deleting file `omniORB4/Naming.hh'
> > >make[3]: Leaving directory
> > >`/amd_tmp/needle-8/users0/cstaff/tpl/SRC/omniORB-4.0.1/omni/build
> /src/lib/o
> > m
> > >niORB'
> > >
> >
> > omniORB 4.0.2
> > I have exactly the same behaviour on HPUX 11.00 with aCC A.03.33 and
> > without -AA
> > Could someone help me to solve (or to understand what the 
> problem is)?
> > Thanks,
> > Pierre.
> >
> >
> > _______________________________________________
> > omniORB-list mailing list
> > omniORB-list at omniorb-support.com
> > http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> >
> 
> 
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20031002/5699ee7f/attachment.htm


More information about the omniORB-list mailing list