[omniORB] omniORB 4.0.2 / omniORBpy 2.2 soon

[Duncan Grisby]

On Thursday 3 July, Serguei Kolos wrote:

> 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

Surely that turns off long long support whether the compiler supports
it or not?  The proper solution is to configure and build Python with
gcc in a mode without long long, then Python's configuration won't set
the define.

Alternatively, you can build omniidl without the -ansi flag, and only
build the omniORB core with -ansi.

> 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?

The utilities have already been changed to use new style standard
headers if they are available. The examples have not been changed,
since to do that would make them harder to read.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --