[omniORB] omniORB 4.0.2 / omniORBpy 2.2 soon

[Serguei Kolos]

Duncan Grisby wrote:

>I intend to release omniORB 4.0.2 and omniORBpy 2.2 in the next week
>or so. If you have any pending bugs to report, or if you have an
>exotic platform that might have been broken, please try out the
>current CVS contents and let me know of any problems.
>
>Thanks,
>
>Duncan.
>

Hello

I am not sure that what I'm reporting are bugs, but nevertheless...

1. My project requirement is to use g++ with '-ansi' switch, in which case
   the compiler does not like the 'long long' type. The problem appears 
in the
   src/tool/omniidl/cxx/idlpython.cc file.
   In the line 176: #include <python_include/python.h> the 'python.h' is 
included.
  This file defines the SIZEOF_LONG_LONG macros, which is also used by the
  omniORB to recognize either the 'long long' type is supported or not
  (file build/include/omniORB4/acconfig.h). I have solved the problem by 
putting the
  following lines to this file just after that include:

#ifndef HAS_LongLong
#undef SIZEOF_LONG_LONG
#endif

It would be very nice if you could fix this in the new omni version.

2. Another point is about new C++ standard header files. The new 
compilers (g++ 3.2
   for example) complain about old style header files like <iostream.h>, 
which are included
   by the omni utilities. They suggest to use the names without '.h' 
like <iostream> for example.
   It is just a warning, but this might become the error in future.
   Do you have plans to converge to the new C++ header files standard in 
the new version?

Cheers,
Sergei