NAME
compat_ibcs2 —
setup procedure for
running iBCS2 binaries
DESCRIPTION
Contrary to what its name indicates, compat_ibcs2 is not a compatibility for
Intel Binary Compatibility Standard 2 (iBCS2) binaries, but rather a
compatibility for SVR3 binaries. This only applies to vax systems. Binaries
are supported from SCO
UNIX and other systems derived
from
AT&T System V Release 3 UNIX. iBCS2
support is only well tested using SCO binaries. XENIX binaries are also
supported although not as well tested. SVR4 binaries are supported by the
COMPAT_SVR4
option.
iBCS2 supports COFF, ELF, and x.out (XENIX) binary formats. Binaries from SCO
OpenServer (version 5.x) are the only ELF binaries that have been tested. Most
programs should work, but not ones that use or depend on:
- kernel internal data
structures
- STREAMS drivers (other than
TCP/IP sockets)
- local X displays (uses a
STREAMS pipe)
- virtual 8086 mode
The iBCS2 compatibility feature is active for kernels compiled with the
COMPAT_IBCS2
option enabled. If support for iBCS2 ELF
executables is desired, the
EXEC_ELF32
option should
be enabled in addition to
COMPAT_IBCS2
.
Many COFF-format programs and most ELF-format programs are dynamically linked.
This means that you will also need the shared libraries that the program
depends on. Also, you will need to create a “shadow root”
directory for iBCS2 binaries on your
NetBSD system.
This directory is named
/emul/ibcs2. Any file operations
done by iBCS2 programs run under
NetBSD will look in
this directory first. So, if an iBCS2 program opens, for example,
/etc/passwd,
NetBSD will first try
to open
/emul/ibcs2/etc/passwd, and if that does not exist
open the ‘real’
/etc/passwd file. It is
recommended that you install iBCS2 packages that include configuration files,
etc. under
/emul/ibcs2, to avoid naming conflicts with
possible
NetBSD counterparts. Shared libraries should
also be installed in the shadow tree.
Generally, you will need to look for the shared libraries that iBCS2 binaries
depend on only the first few times that you install an iBCS2 program on your
NetBSD system. After a while, you will have a
sufficient set of iBCS2 shared libraries on your system to be able to run
newly imported iBCS2 binaries without any extra work.
Setting up shared libraries
How to get to know which shared libraries iBCS2 binaries need, and where to get
them? Depending on the file type of the executable, there are different
possibilities (when following these instructions: you will need to be root on
your
NetBSD system to do the necessary installation
steps).
-
-
- COFF binaries
- You can simply copy all of the available shared libraries
since they are fairly small in size. The COFF shared libraries are
typically found in /shlib and can be obtained from the following sources:
SCO UNIX version 3.x (aka ODT)
SCO UNIX version 5.x (aka OpenServer)
SCO UnixWare
Many versions of SVR4.2/x86
After copying the shared libraries, you should have at least the following
files on your system:
/emul/ibcs2/shlib/libc_s
/emul/ibcs2/shlib/libnsl_s
/emul/ibcs2/shlib/protlib_s
-
-
- ELF binaries
- You can simply copy all of the available shared libraries
from the source system or distribution or use
ldd(1) to determine the
libraries required by a specific binary.
After copying the shared libraries, you should have at least the following
files on your system:
/emul/ibcs2/usr/lib/libc.so.1
/emul/ibcs2/usr/lib/libcrypt.so
/emul/ibcs2/usr/lib/libndbm.so
/emul/ibcs2/usr/lib/libsocket.so.1
If you don't have access to a SCO system, you will need to get the extra files
you need from a SCO distribution. As of January 1998, SCO sells a copy of SCO
OpenServer (iBCS2) and/or SCO UnixWare (SVR4) for personal/non-commercial use
for only the cost of shipping (about $20US). The distribution comes on an
ISO9660-format CDROM which can be mounted and used to copy the necessary
files.
BUGS
The information about SCO distributions may become outdated.
Attempting to a use a nameserver on the local host does not currently work due
to an absurd shortcut taken by the iBCS2 network code (remember that there are
no kernel sockets).
16/32/64 bit offsets may not be handled correctly in all cases.