Linux® libararies are not installed on FreeBSD by default and Linux binary compatibility is not enabled by default. Linux libraries can be installed using the FreeBSD Ports Collection. Alternately, Linux libraries can be installed manually.
Using the Ports Collection is by far the easiest way to install Linux libraries:
# cd /usr/ports/emulators/linux_base-f10# make install distclean
Once the port is installed, enable Linux binary compatibility by loading the linux module. Type the following as root:
# kldload linux
In order for Linux compatibility to always be enabled at boot time, add the following line to /etc/rc.conf:
To verify that the module is loaded, use kldstat(8):
% kldstat Id Refs Address Size Name 1 2 0xc0100000 16bdb8 kernel 7 1 0xc24db000 d000 linux.ko
Users who prefer to statically link Linux binary compatibility into the kernel should add options COMPAT_LINUX to the custom kernel configuration file. Compile and install the new kernel as described in .
While using the Ports Collection is recommended, Linux libraries can be installed manually. The Linux shared libraries required by a program and the runtime linker should be copied to /compat/linux. Any shared libraries opened by Linux programs run under FreeBSD will look in this directory first. For example, if a Linux program loads /lib/libc.so, FreeBSD will first try to open /compat/linux/lib/libc.so, and if that does not exist, it will then try /lib/libc.so. Shared libraries should be installed to /compat/linux/lib rather than to the paths that the Linux ld.so reports.
Generally, one will need to look for the shared libraries that Linux binaries depend on only the first few times that a Linux program is installed on FreeBSD. After a while, there will be a sufficient set of Linux shared libraries on the system to be able to run newly imported Linux binaries without any extra work.
If the linux_base port is installed and an application still complains about missing shared libraries, there are two methods root can use to determine which shared libraries the Linux binaries need.
If a Linux system is available, determine which shared libraries the application needs, and copy them to the FreeBSD system.
In this example, FTP was used to download the Linux binary of Doom on a Linux system . To check which shared libraries it needs, run ldd linuxdoom:
% ldd linuxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
Copy all the files in the last column into /compat/linux on the FreeBSD system, with the names in the first column as symbolic links pointing to them. This example will result in the following files on the FreeBSD system:
/compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
Note: If a Linux shared library already exists with a matching major revision number to the first column of the ldd output, it does not need to be copied to the file named in the last column, as the existing library should work. It is advisable to copy the shared library if it is a newer version, though. The old one can be removed, as long as the symbolic link points to the new one. For example, these libraries exist on the system:
/compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27
and a binary claims to require a later version according to the output of ldd:
libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29
If it is only one or two versions out of date in the trailing digit, do not worry about copying /lib/libc.so.4.6.29, because the program should work fine with the slightly older version. However, it is safe to replace the libc.so:
/compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
Note: The symbolic link mechanism is only needed for Linux binaries as the FreeBSD runtime linker takes care of looking for matching major revision numbers.
ELF binaries sometimes require an extra step of “branding”. If an unbranded ELF binary is executed, it will generate an error message like the following:
% ./my-linux-elf-binary ELF binary type not known Abort
To help the FreeBSD kernel distinguish between a FreeBSD ELF binary and a Linux binary, use brandelf(1):
% brandelf -t Linux my-linux-elf-binary
Since the GNU toolchain places the appropriate branding information into ELF binaries automatically, this step is usually not necessary.
FreeBSD uses its own package database to track all software installed from the Ports Collection. However, the Linux RPM database is not supported.
In order to install a Linux RPM-based application, first install the archivers/rpm2cpio package or port. Once installed, root can use this command to install a .rpm as follows:
# cd /compat/linux# rpm2cpio -q < /path/to/linux.archive.rpm | cpio -id
If necessary, brandelf the installed ELF binaries, but not the libraries. Note that this will prevent a clean uninstall.
If DNS does not work or this error appears:
resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword
Configure /compat/linux/etc/host.conf as follows:
order hosts, bind multi on
This order specifies that /etc/hosts is searched first and DNS is searched second. When /compat/linux/etc/host.conf does not exist, Linux applications use /etc/host.conf and complain about the incompatible FreeBSD syntax. Remove bind if a name server is not configured using /etc/resolv.conf.