Because the provided ABI has been developed in ignorance of actual SVR4 source code, there are bound to be unforeseen interactions between SVR4 client applications and the emulated ABI which cause applications to malfunction.
Additionally, some SVR4 operating systems do not adhere to the SVR4 ELF standard. In particular, Solaris does not set the ELF interpreter field in the ELF header to a value which would allow the kernel to correctly identify a client executable as an SVR4 application. Thus, in certain instances it is necessary to use the brandelf(1) utility to explicitly brand the executable, or to set the kern.fallback_elf_brand sysctl(8) variable to define a "default" ABI for unbranded executables. Value ELFOSABI_SOLARIS represents Solaris; ELFOSABI_SYSV represents other SysVR4 operating systems. See
.In sys/elf_common.h for ELFOSABI branding definitions, and brandelf(1) for information on branding executables.
The svr4 module can be linked into the kernel statically with the COMPAT_SVR4 kernel configuration option or loaded as required. The following command will load the module if it is neither linked into the kernel nor already loaded as a module:
if ! kldstat -v | grep -E svr4elf > /dev/null; then
kldload svr4 > /dev/null 2>&1
The kernel will check for the presence of the streams(4) module, and load it if necessary.
Note that dynamically linked SVR4 executables will require a suitable environment in /compat/svr4.
For information on loading the svr4 kernel loadable module automatically on system startup, see rc.conf(5). This information applies regardless of whether the svr4 module is statically linked into the kernel or loaded as a module.
STREAMS emulation is limited but (largely) functional. Assuming the streams(4) module is loaded, a STREAMS handle can be obtained by opening one of the relevant files in /dev or /compat/svr4/dev. Internally, the streams(4) driver produces a socket descriptor and "tags" it with additional STREAMS state information before returning it to the client application. The svr4 environment uses the additional state information to recognize and manipulate emulated STREAMS handles when STREAMS-specific ioctl(2) calls are executed.
The subset of STREAMS functionality which is provided is small, probably little more than what is required to enable programs on the Solaris CD sets to run.