[omniORB] omniORB 3.0 on WinNT

[Poilpret Jean Francois]

Hi omniORBers,

is there someone out there who already had omniORB3.0 work on the =
following platform:
- Windows NT 4, SP3
-Visual C++ 6.0 (no SP applied)

I already corrected a few problems I encountered (see the end of this =
email), but I think I give up because compiling errors seem to appear =
one after another (just after correcting one, another one takes the =
compiling process just a few lines after before stopping). There are =
some error messages I do not understand (more exactly, I don't =
understand WHY the compiler is troubled).

The last error I had this morning was:

cl -c -O2 -MT -GX -I. -I.\.. -I.\..\.. -DUSE_omniORB_logStream =
-D_OMNIORB_LIBRARY -D NTArchitecture -D _WINSTATIC -I. =
-I..\..\..\..\include -D__WIN32__ -D__x86__ -D__NT__ -D__OSVERSION__=3D4 =
-Fotaskqueue.o -Tptaskqueue.cc
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for =
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

taskqueue.cc
..\..\..\..\include\omniORB3/CORBA.h(978) : warning C4003: not enough =
actual parameters for macro 'OMNIORB_DECLARE_USER_EXCEPTION1'
[... few other warnings like this, not important...]
..\..\..\..\include\omniORB3/poa_defs.h(162) : error C2512: =
'Object::Object' : no appropriate default constructor available
..\..\..\..\include\omniORB3/poa_defs.h(162) : error C2437: 'Object' : =
already initialized
make[3]: *** [taskqueue.o] Error 2
make[2]: *** [export] Error 2
make[1]: *** [export] Error 2
make: *** [export] Error 2

In poa_defs, the lines concerned by this error are:
>>>>
class _objref_AdapterActivator :
  public virtual CORBA::Object, public virtual omniObjRef
{
public:
  CORBA::Boolean unknown_adapter(POA_ptr parent, const char* name);

  inline _objref_AdapterActivator() : CORBA::Object(0) {}  // nil
  _objref_AdapterActivator(const char*, IOP::TaggedProfileList*, =
omniIdentity*, omniLocalIdentity*);

protected:
  virtual ~_objref_AdapterActivator();

private:
  virtual void* _ptrToObjRef(const char*);

  _objref_AdapterActivator(const _objref_AdapterActivator&);
  _objref_AdapterActivator& operator =3D (const =
_objref_AdapterActivator&);
  // not implemented
};
<<<<

particularly the line:
  inline _objref_AdapterActivator() : CORBA::Object(0) {}  // nil

as for me, I see no problem here.So  certainly VC++ is another M$ =
bullsh..
Does someone know if there are SPs for VC++ 6.0 that could make all =
those problems with making omniORB 3.0 disappear ?

Since I had already started some "debugging" in the omniORB 3.0 sources. =
Here is what fixes I had to apply.

1. file "win32.mk"
- the definition of the OMNIORB_IDL_ONLY was including the complete path =
to omniidl3.exe, which was a problem when compiling the IDL files used =
for building the omni core libraries. I had to change the definition =
like this:
OMNIORB_IDL_ONLY =3D omniidl3.exe -h .hh -s SK.cc
(instead of
OMNIORB_IDL_ONLY =3D $(BASE_OMNI_TREE)/$(BINDIR)/omniidl3.exe -h .hh -s =
SK.cc
)

2. file "o2be_utils.h"
- had operator << for StringBuf,=20
because everywhere one used s << sb (s is an ostream, sb a StringBuf), =
the compiler did not automatically invoke the (const char*) cast =
operator of StringBuf, printing the address of StringBuf instead. =
Therefore, after having made omniidl3.exe, any IDL compilation would =
produce files with a lot of garbage. Here, I had two options (in fact =
three, the third would be to give up VC++ ;-)), the first was to add an =
explicit cast everywhere in the code containing s << sb (many places !), =
the second that I chose because it involverd only one place for =
modifications, was to add an operator << specific for StringBuf. I added =
the operator directly inline in the o2be_utils.h file, just after =
definition of the StringBuf class:

inline std::ostream& operator << (std::ostream& s, const StringBuf& sb)
{
   return s << sb.c_str();
}

>From there, it seems that omniidl3 produced correct files (as far as I =
could see in the following of the process, building omniORB libraries)

Just a note here: I don't feel comfortable enough with C++ standard to =
say if this is a problem with MS VC++ implementation, or if one should =
always use explicit cast in this case ?

3. file "userexception.h"
the compiling of this file generated many warnings regarding macros =
requiring two arguments, but having only one, but this was not an issue.
However, I also had an error with what the compiler understood like a =
static member function call for a member function which was not static. =
This problem occurred with macro OMNIORB_DECLARE_USER_EXCEPTION1 =
containing, originally, the following lines:

  inline name& operator=3D(const name& _ex) {  \
    CORBA UserException::operator=3D(_ex);  return *this;  \
  }  \

which I had to change to:

  inline name& operator=3D(const name& _ex) {  \
    static_cast<CORBA UserException *>(this)->operator=3D(_ex);  return =
*this;  \
  }  \

It seems to me that this is a bug in the compiler, not in the code, but =
here again, I'm not quite sure about it.

4. I stopped here, because, unfortunately, I had no time left to go =
further in my investigations...

Just a few words more: I'm sorry that I did not make a path file (I'm =
not used to using diff much). Moreover, my purpose was to achieve, as =
soon as possible, a complete build to be able to test omni3 on my =
platform. I hope that someone will go on (if this was not already done =
?)
=20