Although not permitted by default, there is an option to the UDK linker that forces it to allow mixing of objects from different Application Binary Interfaces (ABIs).
This is not generally recommended, because of the typical mismatches that occur between the binary interfaces of objects conforming to the ABI supported by SCO OpenServer and the ABI supported by the UDK. (See ``UnixWare standards conformance''.)
For example, some of the mismatches that may occur involve:
Some of these differences may be important for calls between your code and the library with which you are linking. Others will be important for the interface between a third-party library and the UDK libc. For example, if a third-party library calls stat(2), it will not work because of the type mismatch discussed in the bullet list above. Another example is code compiled using the SCO OpenServer headers attempting to interface to the UDK libc. This will not work, in the general case. There are many other examples.
(For other examples of the kinds of mismatches that occur between libraries conforming to different ABIs, see the ``Base kernel compatibility'' and ``API compatibility'' topics.)
If you are certain that mixing objects between the UDK and SCO OpenServer ABIs is what you want to do, you can specify linking options to the cc(1) command that allow you to do so.
To allow object mixing and produce an iABI style binary use:
cc -Wl,"-f iabi"...
To allow object mixing and produce an SCO OpenServer style binary use:
cc -Wl,"-f osr5"...
These options assert that the programmer has determined that the binary interfaces among the objects being combining will work together.
See ld(1) for more information on these options.
Another option, of course, is to recompile the SCO OpenServer objects with the UDK and then recompile the application. If you cannot get recompiled library code, you can consider using the SCO OpenServer Release 5 development kit and relying on the SCO OpenServer compatibility in UnixWare 7 to execute your application. (See UNRESOLVED XREF-0.) This solution, however, means that your application will probably not run on SCO UnixWare 2.1.X systems.