[omniORB] Strange behavior of omniORB 4.0.0

Wed Feb 19 14:35:03 2003

I run the same setup with no problems at all (Mandrake 9.0, gcc 3.2,
omniORB4, omniORBpy 2).  Are you sure there aren't omniORB3.0.5 artifacts
getting used by your client/server build process?  Stubs/Skeletons or
shared objects?

Kendall

                      ondrej@frcatel.fri.utc.sk                                                                                   
                      Sent by:                           To:       omniorb-list@omniorb-support.com                               
                      omniorb-list-admin@omniorb-        cc:                                                                      
                      support.com                        Fax to:                                                                  
                                                         Subject:  [omniORB] Strange behavior of omniORB 4.0.0                    

                      02/19/2003 01:59 AM                                                                                         

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
_______________________________________________
omniORB-list mailing list
omniORB-list@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list