[omniORB] problems building omniORB4 on Solaris with SC 4.2
baileyk@schneider.com
baileyk@schneider.com
Tue Dec 17 19:55:02 2002
I think that adding an outermost const to a parameter type is explicitly
allowed in the function definition. For example
void foo(int x);
void foo( const int x )
{
}
Should be OK. I'm not suprised compilers don't complain. I've used the
4.2 version of Sun's compiler and I don't think it ever complained about
such things either. I just tried the 5.3 version in -compat=4 mode and it
didn't complain. I seem to recall an old old version of MSVC++ did not
like it though.
I assume you meant the "-g" is there to work around a version _5_ compiler
bug?
Kendall
Duncan Grisby
<duncan@grisby.org> To: "Lai, Patrick" <Patrick.Lai@broadvision.com>
Sent by: cc: "'omniorb-list@omniorb-support.com'"
omniorb-list-admin@omniorb-s <omniorb-list@omniorb-support.com>
upport.com Fax to:
Subject: Re: [omniORB] problems building omniORB4 on Solaris with
SC 4.2
12/17/2002 11:59 AM
On Thursday 12 December, "Lai, Patrick" wrote:
> - dynAny.cc
> Apparently dynAnyImpl.hh and dynImpl.cc are in consistent. The
> DynAnyFactoryImpl::create_dyn_any_from_type_code() method has different
> signatures in the two files. One takes "CORBA::TypeCode_ptr" whereas
> the other "const CORBA::TypeCode_ptr."
How peculiar. I wonder why other compilers allow it. I'll fix that
before 4.0.1.
> - beforeauto.mk.in
> Some flags are apparently missing for Compiler_Sun4. I copy the
> following flags from the Compiler_Sun5 section:
> CXXDEBUGFLAGS = -O2 -g
Do you really need the -g? That is there to work-around a bug in the
version 4 compiler, so it shouldn't be needed on version 4. I'll put
the other things in (and the -g too if it's really required).
Thanks for reporting these things.
Duncan.
--
-- Duncan Grisby --
-- duncan@grisby.org --
-- http://www.grisby.org --
_______________________________________________
omniORB-list mailing list
omniORB-list@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list