What won't work

Basically you cannot mix and match C++ binary objects between either OpenServer or UnixWare 2.x and the UDK. By "C++ binary objects" this means:

• object files (.o),

• archives (.a),

• and dynamic libraries (.so)

What happens if you do inadvertently mix and match objects?

Attempts to mix OpenServer objects with UDK objects will be detected as an error by the UDK linker:

   non-udk-osr5-machine: CC -c hello.C
   non-udk-osr5-machine: rcp hello.o udk-machine:
   

   udk-machine: CC hello.o
   UX:ld: ERROR: hello.o: fatal error: cannot link OpenServer object into Intel iABI target

Most of the time, attempts to mix UnixWare 2.x objects with UDK objects will also be detected as an error by the UDK linker. An example at the .o level:

   non-udk-uw-machine: CC -c hello.C
   non-udk-uw-machine: rcp hello.o udk-machine:
   

   udk-machine: CC hello.o
   UX:ld: ERROR: attempt to load old C++ object hello.o

And an example at the .so level:

   non-udk-uw-machine: CC -G -o libf.so f.C
   non-udk-uw-machine: rcp libf.so udk-machine:
   

   udk-machine: CC m.C libf.so
   UX:ld: ERROR: attempt to load old C++ object libf.so

But what happens if you simply move a dynamic library created with UnixWare 2.1 into a place where the UDK expects it? The linker is not invoked in such a case, and nothing flags that you have mismatched versions. For example:

f.C:

   #include <stdio.h>
   

   void g();
   

   class A {
   public:
           A() { printf("ctor\n"); }
           ~A() { printf("dtor\n"); }
   };
   

   void f() {
           A a;
           g();
   }

m.C:

   #include <stdio.h>
   

   void f();
   

   void g()
   {
           throw "exception!";
   }
   

   int main() {
           try {
                   printf("main\n");
                   f();
           }
           catch (...) { }
   }

First, build this all with the UDK:

   udk-machine: CC -G -o libf.so f.C
   udk-machine: CC m.C libf.so
   udk-machine: ./a.out
   main
   ctor
   dtor

As we would expect. But what happens if we go to a UnixWare 2.1 machine and build the dynamic library, and then move it into the place where the UDK dynamic library was?

   non-udk-uw-machine: rcp udk-machine:f.C .
   non-udk-uw-machine: CC -G -o libf.so f.C
   non-udk-uw-machine: rcp libf.so udk-machine:
   

   udk-machine: ./a.out
   main
   ctor

The object in function f() wasn't properly destructed when the exception was thrown, because the UnixWare 2.1 C++ ABI didn't contain any exception handling information in it. In a real application this could cause a serious memory leak.

This kind of problem can crop up in many different language areas. You can get unresolved references from the runtime dynamic linker because of missing RTTI information, differences in name mangling, and so forth. You can also get code that just doesn't work, as in the above example.

Similar problems are less likely to show up with mixing OpenServer and UDK objects because C++ dynamic libraries weren't officially supported in OpenServer.