[omniORB] Minor problems compiling omniORB 2.6.1 sources

[Mikhail Soukhanov]

Although I am using the much disfavoured Borland compiler, I think these
two issues may be of general concern.

omniORB version 2.6.1
Platform: Cyrix 6x86MX-PR200+, Windows 95 OSR2 (build 4.00.1111)
Compiler: Borland C++ 5.02 (bcc32 version 5.2) with GNU make

I. FIRST:

While making omniThreads library, BC complains about double ";;" in file
"include/omnithread.h":
> ...
> class _OMNITHREAD_NTDLL_ omni_thread {
> ...
> OMNI_THREAD_EXPOSE:
>     OMNI_THREAD_IMPLEMENTATION		<<< line 503 -- error in the declaration of class
> };
> ...
Tracking the problem down revealed the following defines in file
"include/omnithread/nt.h":
> ...
> #ifndef __BCPLUSPLUS__
> #define OMNI_THREAD_WRAPPER \
>     unsigned __stdcall omni_thread_wrapper(LPVOID ptr);
> #else
> #define OMNI_THREAD_WRAPPER \
>     void _USERENTRY omni_thread_wrapper(void *ptr);	<<< line 37 -- the ";" to be removed
> #endif
> 
> extern "C" OMNI_THREAD_WRAPPER;
> ...
> #define OMNI_THREAD_IMPLEMENTATION          \
> ...
>     friend OMNI_THREAD_WRAPPER;			<<< line 63 -- here the ";" doubles
> ...
Removing the trailing semicolon in line 37 seems the right thing to do
antway and really solves the problem. I wonder if the same semicolon
should be removed in the M$VC section and why the M$VC compiler does not
consider it an error.

II. SECOND:

While making omniORB library, BC complains about an unknown type in file
"src/lib/omniORB2/typecode.cc":
> ...
> CORBA::TypeCode::TypeCode(const char* repoId, const char* name,
>                                    const EnumMemberSeq& members)	<<< line 207 -- error
> {
> ...
Qualifying the type "EnumMemberSeq" with "CORBA::" namespace solves it. 
> ...
> CORBA::TypeCode::TypeCode(const char* repoId, const char* name,
>                             const CORBA::EnumMemberSeq& members)	<<< line 207 -- the right way
> {
> ...
By the way, in other similar methods in this file the types of arguments
are all qualified.

As buggy as BC can be in other situations, I think that these two
inconsistencies are worth correcting in the main source. If it is not
true, I would appreciate your comments.

Best regards,
		Mikhail Soukhanov <mik@astra.relline.ru.>