[omniORB] Re: Bug reports about Solaris 7 / Sun Workshop 5.0 compiler

[Duncan Grisby]

On Friday 17 January, "Hautesserres, Thomas" wrote:

> The problem is that setting the PYTHON variable in the
> mk/platforms/sun4_sosV_5.7.mk file didn't work (either by leaving the PYTHON
> = $(ABSTOP)/$(BINDIR)/omnipython line or setting it to an absolute path like
> PYTHON = /home/diva/Tools/omniORB-4.0.0/bin/sun4_sosV_5.7/omnipython). If we
> do that, the configure script doesn't find the python executable (checking
> for python... no), makes two more errors while checking python version and
> system (?), but finally generates makefiles that won't work. Note: PYTHON
> was set to an empty value in build/mk/beforeauto.mk .

Setting the PYTHON variable in the platform makefile is only used when
you are _not_ using the configure script. If you use the configure
script, you are meant to specify PYTHON in the configure arguments.
That's what it says in README.unix.

> 2) Ambiguities in constructor calls :
> 
> We had problems with the following calls (repeated a couple of times in the
> sources files of src/lib/omniORB/orbcore) :
> 
> cdrMemoryStream buf(CORBA::ULong(0),1);
> cdrEncapsulationStream e(CORBA::ULong(0),1);
> 
> The ambiguity is that the Sun Workshop 5.0 compiler doesn't know that 1 or 0
> is a CORBA::Boolean, so it decides that the constructor call is ambiguous
> and could also be a call to a constructor like :
>   cdrEncapsulationStream(const _CORBA_Octet* databuffer, _CORBA_ULong
> bufsize, _CORBA_Boolean allowAlign4 = 0);
> (because a long can also be a pointer).

Does it produce an error or just a warning?  The strange thing is that
the compile works fine for me with Sun CC 5.2. It worked with 5.0 when
I last had access to that, too. If it really is a problem, the proper
solution will be to explicitly cast to boolean in the calls to the
constructor, rather than adding another constructor.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --