[omniORB] Problems with omniORB3 build on NT

[Ji-Yong D. Chung]

Platform: NT4.0 (SP4) MSVC++

    One of the problems in trying to create omniNames.exe is that, there are
several unresolved symbols when omniDynamic300_rtd.dll is not used as one of
the linker libraries.  One can introduce various kludges to workaround the
problem for various examples (in src/examples directory), but the problem
rears its ugly head when one is trying to debug the omniDynamic300_rtd.dll
using dynExample (Note that if one were to build omniNames by linking it
with omniDynamic300_rtd.dll --  omniNames.exe will crash even before it can
initialize).

    The linking problem also manifests itself EVEN when one is trying to
build omniNames.exe using the static library, omniORB3d.lib.  Again, the
problem is that there are unresolved symbols.

    David Riddoch asked, in one of his emails, if someone has any idea where
these linker errors were coming from.  The answer, it seems, is
"everywhere."

--------------------------------------------------------------------

    From my cursory examination of the source/include files, I think the
following is the problem: There are include files which carry definitions
(not just declarations).  The problematic references (unresolved symbols)
are generated from these definitions.

    For example, In CORBA.h, on line 495, there is the following code:

    inline Any_var& operator=(Any* p)
    {
        if (pd_data) delete pd_data;
       pd_data = p;
       return *this;
    }


    As one can see, the code refers to "delete" operator of Any.  The MSVC
linker tries to resolve this symbol -- which is clearly not available
without msvcdllstub.cc.

----------------------------------------------------------------------------

    Another example:

    In seqtemplates.h (line 139), one has the following code:

        static inline void freebuf(T * b) {
            if (b) delete [] b;
          }


    I traced TypeCode_member class, and apparently, one of the classes
created via the preceding template used TypeCode_member as its parameter.
Since you have inline definition that references the delete operator, the
linker complains.


---------------------------------

    There are probably many, many functions (which are defined as inline
functions in the include and template files) that reference the problematic
symbols (in addition to the ones mentioned above).



----------------------------------------------------------------------------
----------------------


P.S:    The linker probably would NOT have complained if the destructors
were declared virtual (but it may cause other problems if it were), so if
you are writing small programs to test the preceding bug types using
destructors, make sure that they are not declared virtual.