[omniORB] Re: omniORB port to C++ Builder
Wed, 17 Mar 1999 10:38:34 +0300
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=koi8-r
Ian Dees wrote:
> If it's not too much trouble to ask, what basic steps do I have to
> perform to download the latest working version of omniORB, what mods do
> I have to make to the source files, what compiler flags do I need to
> set, etc...?
The most recent version of omniORB compiled with C++Builder, as far as I
know, is 2.7.0 with the successful and failed components listed at
To build it, you have to download and unpack the original omniORB_2.7.0
distribution, download the archive of changes (301 kB) specific to
C++Builder found at
or at <http://astra.relline.ru./devel/omniORB_2.7.0-bcb_3.0.zip> and
unpack it *on top* of the original files. In the sub-directory 'bcb' you
will find a number of projects (.bpg's and .bpr's) which can be opened
and built with C++Builder 3.0 (at least, I think so).
Really it was Thomas van der Ploeg, not me, who has made the main bulk
of changes to port omniORB (then 2.6.1) to Borland, so you will find his
description of the process in the file 'bin/x86_win32cb/bcb_mods.txt'
which is packed into his port found at
As the archive is rather big, I attach the text here. Minor 2.7.0
modifications of mine consisted mostly of out-of-lining certain member
functions (due to some bug in C++Builder compiler, I think) and defining
additional macros for exporting classes and functions from the new
Recently, I have already merged 2.7.1 update changes with my C++Builder
modifications, but had not enough time to test the results yet. I will
inform you as soon as I get it running or, if interested, I can send a
snapshot right now (mail of http).
Have a good time playing with omniORB & C++Builder. Feel sure to ask any
Mikhail Soukhanov <mailto:email@example.com.>
Laboratory of Geoinformatics, VNIIgeosystem
Warszawskoje chaussee 8, Moscow M-105, 113105 Russia
Tel.: +7(095) 954-00-31, fax.: +7(095) 958-35-22
Content-Type: text/plain; charset=koi8-r;
Some notes on BCB projects to build omniORB sources.
All omniORB headers must be compiled with the -b option but VCL libs must be compiled with -b- option.
The option can be turned on and of with pragma's.
In the projects the option -Pcc is also given which makes the compiler compile .cc files as c++ files and not c files.
Turned precompiled headers off for all projects except idl projects, is not always necessairy but just to be sure.
omnithread.H 82 #ifdef _MSC_VER => #if defined( _MSC_VER ) || defined( __BCPLUSPLUS__)
nt.h 37 removed ';' at end of OMNI_THREAD_WRAPPER compiler can't handle ;; in class definitions, thinks it's a declaration that doesn't declare anything.
omnithread.h 506 if creating dll and bc++ then moved omni_thread_init to nt.cc file. not sure about this. but should be alright and enables precompiled headers.
nt.cc 863 added omni_thread_init object if creating dll and bc++.
idl.hh 94 added
#elif defined( __BCPLUSPLUS__ )
#if __BCPLUSPLUS__ >= 0x0530
to enable std and namespace for cbuilder.
utl_edentifier.cc 128 replaced _stricmp with stricmp for borlandc.
drv_preproc.cc function DRV_pre_proc, some functions and defines in borland without underscore so defined macro U_SCORE
#define _(X) X
#define _(X) _##X
used like _(open) borland => open microsoft => _open
at end of function added
drv_preproc.cc function DRV_pre_proc, removed 'const' for 'arglist' as argument to spawnvp
borland function takes char * not const char *. Should be no problem for microsoft.
drv_preproc.cc function DRV_cpp_init, put some CPP32 specific stuff in, see comment there.
How are lex.yy.cc and y.tab.cc compiled in the make files ? added them to the fe.lib
y.tab.cc , moved type defines behind includes, severe conflict with types used by RW std implementation
which are windows types, hope it is alright.
omniidl seems to work, except for -E option, gives "The handle is invalid" message.
CORBA_sysdep.h 176, added
#define __USE_STD_NAMES__ //tell io libs we want to use std::
typecode.cc 207, changed EnumMemberSeq to CORBA::EnumMemberSeq, need scope resolution
same story at lines 236, 2030, 2102, 2466, 2525, 2534
CORBA_sysdep.h 332, added borland dll/static etc macro's
log.h, NAMINGCONTEXT_I.H, omniNames.cc, NamingContext.cc and log.cc replaced class log with class logger since seems to be a name conflict (be it right or not) with a log object in the runtime libs.
omniNames.cc, 119 function main inserted ifdef __BORLANDC__ etc. because naming different from microsoft
log.cc 133 method logger::logger (log::log), replaced #ifdef __WIN32__ with #ifdef _MSC_VER since not true for CBuilder.
log.cc 277 same thing in same method.
log.cc 335 method logger::init (log::init) inserted ifdef __BCPLUSPLUS__ etc. because rw im of fstreams does not support attach
log.cc 468 same method same thing same reason.
log.cc 571 method logger::checkpoint same thing same reason.
log.cc 696 same method same thing same reason.
Tried for long time to devise method to export publics in a way it is done with VC now. could not find one.
Long time the linker map file was my hope but for some reason it does not put every public in the map.
Probably only those publics that it thinks it needs.
I loath to put macro's in all the source to do export/import but I am afraid i'll have to.
CORBA_sysdep.h 419, #define _CORBA_MODULE_FN _LC_attr, same at lines 437, 443
CORBA_sysdep.h 447, added #define _CORBA_MODULE_CLASS _LC_attr to export classes in bcb.
CORBA_sysdep.h 563, some for non have namespace situations
CORBA.h all relevant occurances of class and struct replaced with 'class _CORBA_MODULE_CLASS' and struct '_CORBA_MODULE_CLASS' (didn't want to do this but don't know how else to export everything)
Saw funny problem compiling naming.hh in preprocessor. Gave faulty 'unexpected end of file in conditional started on line 1' must have something to do
with internally stored file length. after trying manny times to fix it in the editor it was fixed when I removed the file out of the IDE.
mods omni idl to enable building stub libs.
idl.hh 76 and 104, defines macro _MODULE_IMPORT to enable exportable/importable stubs for bc
o2be_array.cc 457 inserted _MODULE_IMPORT
o2be_exception 87 inserted _MODULE_IMPORT
o2be_interface inserted _MODULE_IMPORT in many places
now I browse the idl code, what hapens if I name an interface _CORBA_MODULE?
Shouldn't words like these be inserted in the reserved words list, or just not use them?
o2be_struct 210 inserted _MODULE_IMPORT
o2be_union 288 inserted _MODULE_IMPORT
I don't know if it is correct that always both corba core stuff and stub_dll_stuff get same export/imort modifiers.
If I build stub dll then all omniorb functions get exported as well in stub dll but should be imported.
_OMNIORB_CORE_NTDLL_IMPORT to take place of _OMNIORB_NTDLL_IMPORT in CORBA.h default it will expand to
_OMNIORB_NTDLL_IMPORT except when _OMNIORB2_STUB_DLL is defined, then it will expand to __declspec(dllimport) (if needed)
see CORBA_sysdep.h 621 and 363 and CORBA.h 107
modified NamingSK.cc manually to include corba.h instead of naming.hh otherwise nothing of NamingSK gets exported.
modified Naming.hh manually so that will export/import with _OMNIORB_CORE_NTDLL_IMPORT instead of _OMNIORB_NTDLL_IMPORT since it is part of core.
introduced new define _CORBA_GLOBAL_FN in CORBA_sysdep.h (557 and 436 )to export/import some global functions
used it in CORBA_basetypes.h, CORBA.h
introduced _CORBA_GLOBAL_CLASS in CORBA_sysdep.h to export/import global classes
used it in CORBA_basetypes.h, omniinternal.h, seqtemplates.h, iop.h, giop.h, iiop.h, proxyFactory, rope.h
used CORBA_MODULE_CLASS in omniORB.h
in both CORBA_basetypes.h, seqtemplates.h, iop.h, giop.h, iiop.h, omniinternal.h, omniORB.h, proxyFactory, rope.h AND corba.h introduced needed _LC_attr defines