Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Absolute BSD - The Ultimate Guide To FreeBSD (2002).pdf
Скачиваний:
25
Добавлен:
17.08.2013
Размер:
8.15 Mб
Скачать

Foreign Software Libraries

While the kernel portion of the ABI solves one major issue, the other portions of the system are another problem because every operating system has its own requirements in addition to the kernel. The biggest issue is shared libraries. If the kernel starts a program, and the program can't find its shared libraries, it won't work correctly. No matter which ABI you use, you must have a copy of the shared libraries for that platform.

SVR4 and SCO

For example, to use the SVR4 and SCO ABIs, you need access to the appropriate system. While a Sun Solaris 2.6 CD will suffice for the SVR4 module, you need to grab the shared libraries from an actual SCO UNIX machine to use the SCO ABI, which means you need a SCO or Solaris license. This isn't an insurmountable problem, of course, but it does make using this module slightly more difficult—and definitely more expensive.

OSF/1

A minimal set of OSF/1 shared libraries are available under /usr/ports/emulators/osf1_base. These libraries have a restrictive license and can only be used in fairly narrow circumstances, but you can get a more complete set of shared libraries from an actual OSF/1 system, if you wish. If you have an actual OSF/1 license, you can pretty much do whatever you like with the libraries.

Linux

The shared libraries for the Linux mode are the most freely available of any mode. Since the barrier to entry is so low, we'll discuss Linux compatibility in some detail. Once you have a thorough understanding of how it works, you can apply this knowledge to any other ABI compatibility you need to implement.

[2]If you have a spare Alpha lying around (other than the Multia model known for Random Heat Death), feel free to ship it to me in care of No Starch Press; I'll be delighted to include a discussion of OSF/1 mode in the next edition of Absolute BSD.

Installing and Enabling Linux Mode

The simplest way to install and enable Linux mode is with /usr/ports/emulators/linux_base, which downloads and installs a large subset of a typical Linux environment into /usr/compat/linux. (It also adds LINUX_ENABLE=``YES'' to /etc/rc.conf, so that the Linux ABI kernel module will be started when the system boots.)

Depending on what software you've installed, you might already have Linux mode enabled on your system. It runs transparently enough that the ports collection might have installed it without your even knowing! To find out, check /var/db/pkg to see if linux_base is installed. Then use kldstat(8) to see if the Linux ABI kernel module is loaded:

...............................................................................................

# kldstat

Id Refs Address

Size

Name

1

3

0xc0100000

236ff8

kernel

2

1

0xc0337000

54f8

vesa.ko

3

1

0xc119b000

12000

linux.ko

#

 

 

 

 

...............................................................................................

259

As you can see, the last module in the preceding list is the Linux ABI module, linux.ko. If the Linux module is not loaded, it won't appear in the list.

If the module is not loaded, you can load it with kldload(8), as discussed in Chapter 4:

...............................................................................................

# kldload linux

#

...............................................................................................

To automatically load the Linux module at boot, add this line /etc/rc.conf:

...............................................................................................

LINUX_ENABLE=``YES''

...............................................................................................

You should now be able to run Linux programs without any further configuration.

Identifying Programs

Modern UNIX binaries are in ELF format, which includes space for a comment, or brand. A binary will be executed by the ABI for the brand. If a binary has no brand, it is assumed to be a FreeBSD binary. FreeBSD recognizes four different brands: FreeBSD, Linux, Solaris, and SVR4.

While you cannot directly view the brand on a binary, you can examine and manipulate branding with brandelf(1). To check the branding on a binary, just run brandelf on it:

...............................................................................................

# brandelf /bin/sh

File '/bin/sh' is of brand 'FreeBSD' (9).

#

...............................................................................................

Here you see that this program is branded with FreeBSD, so it will be executed under the FreeBSD ABI.

If you have a foreign program that will not run, check its brand. If it isn't branded, you've probably discovered your problem: FreeBSD is trying to run the program under its native ABI. Change this by setting the brand manually with brandelf −t. For example, to brand a program with Linux, do this:

...............................................................................................

# brandelf −t Linux /usr/local/bin/program

#

...............................................................................................

The next time you try to run the program, it will attempt to run under the Linux ABI. If it's a Linux program, it should give you better results.

260

What Is Linux_base?

The Linux kernel module handles the kernel support for Linux compatibility, and if you decide to use the ABI for another UNIX, you'll need to implement much of this on your own. As such, it's a good idea to understand how Linux mode works, to help you troubleshoot problems with other compatibility modes.

One piece of the puzzle is to use the linux_base package. This package extracts a subsection of a Red Hat Linux install under /usr/compat/linux. If you take a look there, you'll see something like the following:

...............................................................................................

#ls

 

bin boot etc lib mnt opt proc sbin usr

var

#

 

...............................................................................................

Looks a lot like the contents of your root directory, doesn't it? Well, if you poke around a bit, you'll find that, generally speaking, the contents of /usr/compat/linux are comparable to that of the main FreeBSD install. You'll find many of the same programs that you do on a base FreeBSD install.

Note One thing Linux devotees notice immediately is that the contents of linux_base are rather minimal compared to what a Linux user is used to. You can add Linux programs to linux_base as you like; we'll look at doing this later.

The Linux ABI tries to stay under /usr/compat/linux whenever possible. (It's somewhat like a weak jail.) When you execute a Linux binary that calls other programs, the Linux ABI first checks for the program under /usr/compat/linux. If it doesn't find the program there, it checks in the main FreeBSD system.

For example, suppose you have a Linux binary that calls ping(8). The ABI will first check under /usr/compat/linux for the ping program. When it finds that it's not there, the ABI will then check the main FreeBSD system and will use /sbin/ping.

Alternatively, suppose a Linux binary wants to call sh(1). The Linux ABI will first check under /usr/compat/linux and find bin/sh. When it finds sh there, it will execute that program instead of the FreeBSD native /bin/sh.

Adding to Linux_base

As I mentioned earlier, the Linux install in linux_base is rather minimal, and some Linux programs expect a broader range of shared libraries to be available. FreeBSD tries to keep ports as small as possible, but compromises by making these additional Linux libraries available as additional ports. The ports collection includes several ports that augment linux_base, most of which are shared libraries. These increase the range of programs that FreeBSD's Linux mode can support. These ports include the following:

devel/linux−libglade is a graphic interface library required by various programs.

devel/linux_devel is a collection of tools for developing Linux programs on FreeBSD.

261

devel/linux_kdump is a Linux binary debugging tool.

graphics/linux−jpeg contains shared libraries to handle JPEG image files.

graphic/linux−png installs shared libraries to handle PNG image files.

graphic/linux−tiff includes shared libraries to handle TIFF image files.

Installing these ports will round out 99 percent of the functionality you might want to provide to a Linux program.

You may need a shared library or program that is not available in linux_base or a port. If so, the simplest thing to do is to find a Linux system of the appropriate version, copy the files, and install them in the appropriate locations under /usr/compat/linux. If you've created a new directory to contain shared libraries, you'll need to tweak /usr/compat/linux/etc/ld.so.conf.

Configuring Linux Shared Libraries

FreeBSD's method for configuring shared libraries is very different from Linux's. Linux creates a cache file from a plain−text configuration file, like the one found at /usr/compat/linux/etc/ld.so.conf:

...............................................................................................

# cat ld.so.conf

/usr/i486−linux−libc5/lib

/usr/X11R6/lib

#

...............................................................................................

The initial slashes in these paths are misleading. Why? Remember, the Linux ABI looks for files under /usr/compat/linux first, and if it finds the files, it uses them. These directories are actually /usr/compat/linux/usr/i486−linuxlibc5/lib and /usr/compat/linux/usr/X11R6/lib. If you look in these directories, you'll find the Linux shared libraries installed by linux_base. The Linux ABI kernel module runs Linux ldconfig(8) to read this file, scan the directories listed, and create or update /usr/compat/linux/etc/ld.so.cache.

When you add shared libraries to your Linux installation, you need to update this cache. You can do this by unloading and reloading the Linux kernel module, but this might interrupt service. Instead, you can run the cacheupdating program:

...............................................................................................

# /usr/compat/linux/sbin/ldconfig

#

...............................................................................................

You won't get any output back, but you can check the date on ld.so.cache to be sure that the cache has been updated. If the date is current, the cache has been updated.

To help keep things organized, if you add shared libraries to your system you can put them in a separate directory. For example, I frequently create /usr/compat/linux/usr/local/lib for whatever random crud I want to add to that system. To use those libraries, however, I must add the path to ld.so.conf. (Remember to strip off the initial /usr/compat/linux, however!)

262