[omniORB] Re: omniORB3 with Borland C++ compiler

[mik@geosys.ru]

Hello, Duncan!

22.05.01 15:00:47, Duncan Grisby <dgrisby@uk.research.att.com> wrote:
>
>I don't think we have the patches for that, do we? 

I have mentioned my port on the omniorb-list somewhat a month ago but not very loudly for the reasons which follow. Over all, it is really successful -- libraries, utilities and 
examples all do compile and run, and we use it here in our under-development corporate GIS software. Though, it still has two shortcomings to be mentioned: 

1. Borland-specific makefiles are not integrated with the others (Omni Development Environment, isn't it?) -- simply due to my lack of spare time;

2. The re-compiled omniidl crashes somewhere in the Python interpreter -- there was recently Borland-related discussion on the python-list, but not very active or resultative one. 
Personally, I do not have much insight into Python internals to solve the problem single-handed. For a time being, the MSVC pre-compiled omniidl.exe is in use.

However, the description of the Borland port of omniORB3 is available from my page at http://astra.geosys.ru./devel/#omniORB3, as well as the links to the sources, patches, 
and binaries.

>If the patches aren't too extensive, 
>we'll integrate them with the main omniORB tree.

The patches themselves are in the zip-packed archive http://astra.geosys.ru./devel/omniORB3/omniORB303_bcc32-patches.zip (about 61 kB). There is a README file 
describing the specific patches in the subdirectory src/x86_bcc32/patches of the archive.

As to their extensiveness, most of them deal with explicit export of omniORB classes and functions from core and dynamic DLLs (I prefer this way of building omniORB for the L-
GPL reasons). These consist of defining _core_lib and _dyn_lib macros and putting them into each "class _core_lib foo { ... }" declaration. The omniORB macros _core_attr 
and _dyn_attr could be used for the purpose with some modification but I used different names to distinguish my changes in the porting process.

A small number of other changes fix the Borland-specific spelling of OS-level function calls.

By the way, here is a question on which classes and functions should be exported by omniORB? At first, I thought that exporting only from the headers in 
<omni>/include/omniORB3 should be sufficient. But when I started building utilities and examples, they required extra stuff to be exported from the [omniORB-internal?] headers 
in <omni>/src/lib/omniORB2 and even from the *SK.cc stubs (!). The MSVC way of exporting every public symbol makes it irrelevant, but maybe the code is improperly 
structured or what? I found all this rather confusing, and would appreciate some enlightment on the subject from omniORB authors.

If I can be of any help with integrating Borland-specific changes into the main omniORB tree, please write.

>> But how do one enable omniidl (MSVC prebuilt) to recognise long long?
>
>It already does, doesn't it?

No, at least with dynamic support. omniidl generates the stubs, but also produce the output:

c:>omniidl -bcxx -Wbh=.hh -Wbs=SK.cc -Wba -Wbuse_quotes TimeBase.idl
omniidl: Fatal error in C++ backend
omniidl:
omniidl: Long long type is not supported with -Wba in this release

Is this really fatal, or the generated stubs can still be used?

Best regards,
		Mikhail

Dr. Mikhail Soukhanov <mailto:mik@geosys.ru.>

Laboratory of Geoinformatics, VNIIgeosistem
Warszawskoje chaussee 8, Moscow M-105, 113105 Russia
Tel.: +7(095) 954-21-50 (x101), fax.: +7(095) 958-35-22
W.W.W.: <http://www.geosys.ru./>