[omniORB] Strange behavior of omniORB 4.0.0

ondrej@frcatel.fri.utc.sk ondrej@frcatel.fri.utc.sk
Wed Feb 19 08:00:02 2003


Hi all,

	after some time after omniORB 4.0.0 was released I have got myself to try
it out. I highly appreciate the new configure; make; make install
standard build procedure both at omniORB and omniOrbPy packages.
 	But I run into problems just after that. I have tried to build a C++
CORBA server and write Python client to it. The server was written for
omniORB 3.0.5 and worked fine. After slight modification of the Makefile
(and changed omniORB3 to omniORB4 in ORB_init) the build was
successfull.
	Then I wrote the Python client. With previous versions of omniORB (3.0.5)
and omniOrbPy the client received SIGABRT  a died. Now it worked, but it
received CORBA::BAD_OPERATION_UnRecognisedOperationName exception. That's
a real failure, because the operation names surely (100%) match. I was
digging in the code of generated skeletons and omniORB itself and it
fails in omniObjRef::_dispatch (if I am not wrong). I tried a C++ client
too to ake sure, that the error is not in Python to omniORB glue. I
received exactly the same exception.

	Then I decided to try another example. Both server and client was written
in C++ and everything worked fine.

	And finally, I tried to write new IDL file and client and server for it.
But I got compilation errors when compiling skeleton files. This happened
on two independent new IDLs.

	From the facts above I think that the problem is the generated code,
which is incompatible with gcc 3.x.x compilers.

	I run Mandrake Linux 9.0 with gcc/g++ 3.2, omniOrb 4.0.0, omniOrbPy 2.0.
Has anyone else encountered the same problem as I have ?

					Ondrej