Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (NetBSD-2.0)
Apropos / Subsearch:
optional field

COMPAT_SVR4(8)            BSD System Manager's Manual           COMPAT_SVR4(8)

     compat_svr4 -- setup procedure for running SVR4/iBCS2 binaries
     compat_svr4_32 -- setup procedure for running 32-bit SVR4/iBCS2 binaries

     NetBSD supports running SVR4/iBCS2 binaries. This code has been tested on
     i386 (with binaries from SCO OpenServer and XENIX), m68k (with binaries
     from AMIX) and sparc (with binaries from Solaris) systems. Most programs
     should work, but not ones that use or depend on:

           kernel internal data structures
           the /proc filesystem
           the ticotsord loopback RPC mechanism (NIS uses this)
           sound and video interfaces
           threads (ttsession uses threads)
           the streams administrative driver

     The SVR4 compatibility feature is active for kernels compiled with the
     COMPAT_SVR4 option enabled.  Since support for ELF executables is
     included only if the kernel is compiled with the EXEC_ELF32 or EXEC_ELF64
     options enabled, kernels which include COMPAT_SVR4 should also typically
     include EXEC_ELF32 (for 32-bit ELF support) and/or EXEC_ELF64 (for 64-bit
     ELF support).

     Another compatibility feature is COMPAT_SVR4_32, which allows the execu-
     tion of 32-bit SVR4 binaries on a machine with a 64-bit kernel. This
     requires EXEC_ELF32 and COMPAT_NETBSD32 options as well as COMPAT_SVR4.
     It is configured the same way as COMPAT_SVR4 but uses the /emul/svr4_32
     directory instead of /emul/svr4.  But typically, /emul/svr4_32 can be
     made to point to /emul/svr4 if the operating system donating the
     libraries has support for both 32-bit and 64-bit binaries.

     Execution of 32-bit SVR4 binaries on a machine with a 32-bit kernel uses
     COMPAT_SVR4, not COMPAT_SVR4_32.

     Most SVR4 programs are dynamically linked. This means that you will also
     need the shared libraries that the program depends on and the runtime
     linker. Also, you will need to create a ``shadow root'' directory for
     SVR4 binaries on your NetBSD system. This directory is named /emul/svr4.
     Any file operations done by SVR4 programs run under NetBSD will look in
     this directory first. So, if a SVR4 program opens, for example,
     /etc/passwd, NetBSD will first try to open /emul/svr4/etc/passwd, and if
     that does not exist open the 'real' /etc/passwd file. It is recommended
     that you install SVR4 packages that include configuration files, etc
     under /emul/svr4, to avoid naming conflicts with possible NetBSD counter-
     parts. Shared libraries should also be installed in the shadow tree.

     The simplest way to set up your system for SVR4 binaries is:
     1.   Make the necessary directories:

                (me@netbsd) mkdir -p /emul/svr4/{dev,etc}
                (me@netbsd) mkdir -p /emul/svr4/usr/{bin,lib,ucblib}
                (me@netbsd) mkdir -p /emul/svr4/usr/openwin/{bin,lib}
                (me@netbsd) mkdir -p /emul/svr4/usr/dt/{bin,lib}

     2.   Copy files from an svr4 system:

                (me@svr4) cd /usr/lib
                (me@svr4) tar -cf - . | \
                     rsh netbsd 'cd /emul/svr4/usr/lib && tar -xpf -'

                (me@svr4) cd /usr/ucblib
                (me@svr4) tar -cf - . | \
                     rsh netbsd 'cd /emul/svr4/usr/ucblib && tar -xpf -'

          If you are running openwindows:

                (me@svr4) cd /usr/openwin/lib
                (me@svr4) tar -cf - . | \
                     rsh netbsd 'cd /emul/svr4/usr/openwin/lib && tar -xpf -'
                (me@svr4) cd /usr/dt/lib
                (me@svr4) tar -cf - . | \
                     rsh netbsd 'cd /emul/svr4/usr/dt/lib && tar -xpf -'
     3.   You will also probably need the timezone files from your Solaris
          system, otherwise emulated binaries will run on UTC time.

                (me@netbsd) mkdir -p /emul/svr4/usr/share/lib/zoneinfo
                (me@netbsd) mkdir -p /emul/svr4/etc/default
                (me@svr4) cd /usr/share/lib/zoneinfo
                (me@solaris) tar -cf -. | \
                     rsh netbsd 'cd /emul/svr4/usr/share/lib/zoneinfo &&
                     tar -xpf -'
                (me@netbsd) echo TZ=US/Pacific > /emul/svr4/etc/default/init
     4.   Set up the configuration files and devices:

                (me@netbsd) cd /usr/share/examples/emul/svr4/etc
                (me@netbsd) cp netconfig nsswitch.conf /emul/svr4/etc
                (me@netbsd) cp SVR4_MAKEDEV /emul/svr4/dev
                (me@netbsd) cd /emul/svr4/dev && sh SVR4_MAKEDEV all

          As the major number allocated for emulation of SVR4 devices may vary
          between NetBSD platforms, the SVR4_MAKEDEV script uses the uname(1)
          command to determine the architecture the devices nodes are being
          created for; this can be overridden by setting the MACHINE environ-
          ment variable accordingly.

     An alternative method is to mount a whole SVR4 partition in /emul/svr4
     and then override with other mounts /emul/svr4/etc and /emul/svr4/dev.

     Many system calls are still not emulated. The streams emulation is incom-
     plete (socketpair does not work yet).

     Most SVR4 executables can not handle directory offset cookies > 32 bits.
     More recent ones, compiled for large file support (Solaris 2.6 and up)
     can. With older programs, you will see the message ``svr4_getdents: dir
     offset too large for emulated program"'' when this happens. Currently,
     this can only happen on NFS mounted filesystems, mounted from servers
     that return offsets with information in the upper 32 bits. These errors
     should rarely happen, but can be avoided by mounting this filesystem with
     offset translation enabled. See the -X option to mount_nfs(8).  The -2
     option to mount_nfs(8) will also have the desired effect, but is less

BSD                             April 19, 1999                             BSD