[omniORB] How to link to x86_win32 binaries with Borland C++b uilder?

[Thomas van der Ploeg]

I think I encountered only two true compiler bugs.
One is the need for the -b switch for CBuilder to compile omniorb code, it
should not have been necessary, certainly not because VCL does not work with
-b switch on.
The other is that the precompiled headers often get funny but it is easy to
switch that off.
I must say that I made it a habit to keep omni and VCL code as separated as
possible and may have and think I have avoided a lot of problems in that
way.
At the moment I am not completely happy about how I did set up the project
for CBuilder, it is not completely consistend with the original omniorb
project ( naming of libs and such ).

But, yes I did get it running and it still runs fine for my purposes, though
I must admit I never tried a complete test for all functionality.
In fact I thought that at last I had found a commercial compiler that has
namespaces implemented correctly.

Regs,

Thomas.

> -----Original Message-----
> From:	dmorgen@alum.mit.edu [SMTP:dmorgen@alum.mit.edu]
> Sent:	Wednesday, November 11, 1998 5:21 PM
> To:	Thomas van der Ploeg
> Cc:	'Gregor'; omniorb-list@orl.co.uk
> Subject:	Re: [omniORB] How to link to x86_win32 binaries with Borland
> C++b uilder?
> 
> Thomas,
> 
> >The DLL's are microsoft DLL's.
> >I am not sure about how much name-mangling is standardized in c++ but I
> gave
> >up trying to link them.
> >It is however possible build everything after some 'minor' modifications
> >using C++ Builder.
> >Major changes are that you have to export inner classes explicitly,
> CBuilder
> >uses the standard io classes and some other
> >io functions work slightly different fom microsofts.
> >Other important point is that the omniorb sources and headers must be
> >processed using integer allignment for enumerators ( -b option I think )
> and
> >the VCL libraries explicitly not.
> >It is not a simple switch but in this way I was able to compile and use
> >omniorb 2.5.0 and soon I hope to do the same thing with omniorb 2.6.1.
> 
> In my reply I missed the point in the original message about trying to use
> the
> included DLLs;  you're correct of course about not being able to mix BCB &
> the
> MSFT DLLs.
> 
> However, when it comes to a full build using BCB3 ... you were actually
> able to
> get it going?  How did you handle the numerous BCB compiler bugs (mostly
> dealing
> with namespaces & overloaded functions, as I recall)?  Fortunately, I was
> able
> to take a totally different approach before having to deal with the last
> bug I
> encountered ... I forget what it was, but it looked like there wouldn't be
> a
> simple workaround.  IAE, it was getting very frustrating to workaround one
> compiler bug, only to find another!
> 
> BTW, I was also using omniORB 2.5.
> 
> =======================================================
> Dave Morgenlender
> e-mail: dmorgen@alum.mit.edu
> =======================================================