[omniORB] Re: problem compiling omniORB 3 on IRIX

[David Riddoch]

On Wed, 20 Oct 1999, James Riden wrote:

> I'm experiencing a problem with the MIPSpro 7.2.1 compiler on 
> IRIX 6.5  It seems to need fully (or more fully) qualified 
> names when invoking superclass constructors in an initializer
>  list.
> 
> For instance,  the following piece of code from include/omniORB3/
> userexception.h :
> 
> >#define OMNIORB_DECLARE_USER_EXCEPTION(name, attr)  \
> >  \
> >class name : public CORBA::UserException {  \
> >public:  \
> >  inline name() {  \
> >    pd_insertToAnyFn    = insertToAnyFn;  \
> >    pd_insertToAnyFnNCP = insertToAnyFnNCP;  \
> >  }  \
> >  inline name(const name& _ex) : CORBA::UserException(_ex) {}  \
>                                   ^^^^^^^
>                                inserted by me

The problem is I think MSVC will get upset if we do it that way.  And I
would have though that this ought to cause problems elsewhere in the code.
Let me know if you see other problems.


> now compiles OK.  (I'm assuming that the behaviour of the MIPSpro
> compiler is at variance with the standard, since everything else 
> compiles it OK.)
> 
> Also from Naming.hh, the following causes a compile error :
> 
> > class _objref_BindingIterator :
> >    public virtual CORBA::Object, public virtual omniObjRef
> >  {
> >  public:
> >    CORBA::Boolean next_one(Binding_out b);
> >    CORBA::Boolean next_n(CORBA::ULong how_many, BindingList_out bl);
> >    void destroy();
> >
> >    inline _objref_BindingIterator() : Object(0) {}  // nil
>                                         ^^^^^^^
> Now, I thought that was calling the ctor of CORBA::Object, but there
> doesn't seem to be one that takes a 0 as a parameter.  

Yes -- that got changed in a recent update.  It looks to me as though you
either need to re-compile the omniidl3 compiler, or regenerate Naming.hh,
NamingSK.cc and all the other generated files in the build.  I suggest you
do a CVS update and a clean build.


Cheers,
David