svn commit: r44294 - head/en_US.ISO8859-1/books/handbook/linuxemu
Dru Lavigne
dru at FreeBSD.org
Thu Mar 20 14:40:53 UTC 2014
Author: dru
Date: Thu Mar 20 14:40:52 2014
New Revision: 44294
URL: http://svnweb.freebsd.org/changeset/doc/44294
Log:
Some more edits to Linux Emulation.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/linuxemu/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/linuxemu/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/linuxemu/chapter.xml Thu Mar 20 04:13:05 2014 (r44293)
+++ head/en_US.ISO8859-1/books/handbook/linuxemu/chapter.xml Thu Mar 20 14:40:52 2014 (r44294)
@@ -146,52 +146,24 @@ Id Refs Address Size Name
described in <xref linkend="kernelconfig"/>.</para>
<sect2 xml:id="linuxemu-libs-manually">
- <title>Installing Libraries Manually</title>
-
- <para>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 <filename>/compat/linux</filename>. Any shared
- libraries opened by &linux; programs run under &os; will look
- in this directory first. For example, if a &linux; program
- loads <filename>/lib/libc.so</filename>, &os; will first try
- to open <filename>/compat/linux/lib/libc.so</filename>, and if
- that does not exist, it will then try
- <filename>/lib/libc.so</filename>. Shared libraries should be
- installed to <filename>/compat/linux/lib</filename> rather
- than to the paths that the &linux; <command>ld.so</command>
- reports.</para>
-
- <para>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 &os;. 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.</para>
-
- <sect3>
- <title>How to Install Additional Shared Libraries</title>
+ <title>Installing Additional Libraries Manually</title>
<indexterm>
<primary>shared libraries</primary>
</indexterm>
- <para>If the <literal>linux_base</literal> port is installed
- and an application still complains about missing shared
- libraries, there are two methods
- <systemitem class="username">root</systemitem> can use to
- determine which shared libraries the &linux; binaries
- need.</para>
-
- <para>If a &linux; system is available, determine which shared
- libraries the application needs, and copy them to the &os;
- system.</para>
-
- <informalexample>
- <para>In this example, FTP was used to download the &linux;
- binary of <application>Doom</application> on a &linux;
- system . To check which shared libraries it needs, run
- <command>ldd linuxdoom</command>:</para>
+ <para>If a &linux;
+ application complains about missing shared
+ libraries after configuring &linux; binary compatibility,
+ determine which shared libraries the &linux; binary
+ needs and install them manually.</para>
+
+ <para>From a &linux; system,
+ <command>ldd</command> can be used to determine which shared
+ libraries the application needs. For example, to
+ check which shared libraries <command>linuxdoom</command> needs, run
+ this command from a &linux; system that has
+ <application>Doom</application> installed:</para>
<screen>&prompt.user; <userinput>ldd linuxdoom</userinput>
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
@@ -201,10 +173,10 @@ libc.so.4 (DLL Jump 4.5pl26) => /lib/
<indexterm>
<primary>symbolic links</primary>
</indexterm>
- <para>Copy all the files in the last column into
+ <para>Then, copy all the files in the last column of the output from the &linux; system into
<filename>/compat/linux</filename> on
- the &os; system, with the names in the first column as
- symbolic links pointing to them. This example will result
+ the &os; system. Once copied, create symbolic links to the names in the first column.
+ This example will result
in the following files on the &os; system:</para>
<screen>/compat/linux/usr/X11/lib/libXt.so.3.1.0
@@ -214,8 +186,6 @@ libc.so.4 (DLL Jump 4.5pl26) => /lib/
/compat/linux/lib/libc.so.4.6.29
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29</screen>
- <blockquote>
- <note>
<para>If a &linux; shared library already exists with a
matching major revision number to the first column of
the <command>ldd</command> output, it does not need to
@@ -223,61 +193,53 @@ libc.so.4 (DLL Jump 4.5pl26) => /lib/
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:</para>
+ link points to the new one.</para>
+
+ <para>For example, these
+ libraries already exist on the &os; system:</para>
<screen>/compat/linux/lib/libc.so.4.6.27
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27</screen>
- <para>and a binary claims to require a later version
- according to the output of
- <command>ldd</command>:</para>
+ <para>and <command>ldd</command> indicates that a binary requires a later version:</para>
<screen>libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29</screen>
- <para>If it is only one or two versions out of date
- in the trailing digit, do not worry about copying
- <filename>/lib/libc.so.4.6.29</filename>, because
- the program should work fine with the slightly older
+ <para>Since the existing library is only one or two versions out of date
+ in the last digit,
+ the program should still work with the slightly older
version. However, it is safe to replace the
- <filename>libc.so</filename>:</para>
+ existing <filename>libc.so</filename> with the newer version:</para>
<screen>/compat/linux/lib/libc.so.4.6.29
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29</screen>
- </note>
- </blockquote>
- <blockquote>
- <note>
- <para>The symbolic link mechanism is
- <emphasis>only</emphasis> needed for &linux; binaries
- as the &os; runtime linker takes care of looking for
- matching major revision numbers.</para>
- </note>
- </blockquote>
- </informalexample>
- </sect3>
+ <para>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 &os;. After a
+ while, there will be a sufficient set of &linux; shared
+ libraries on the system to be able to run newly installed
+ &linux; binaries without any extra work.</para>
</sect2>
<sect2>
- <title>Installing &linux; ELF Binaries</title>
+ <title>Installing &linux; <acronym>ELF</acronym> Binaries</title>
<indexterm>
<primary>Linux</primary>
<secondary>ELF binaries</secondary>
</indexterm>
- <para>ELF binaries sometimes require an extra step of
- <quote>branding</quote>. If an unbranded ELF binary is
- executed, it will generate an error message like the
- following:</para>
+ <para><acronym>ELF</acronym> binaries sometimes require an extra step.
+ When an unbranded <acronym>ELF</acronym> binary is
+ executed, it will generate an error message:</para>
<screen>&prompt.user; <userinput>./my-linux-elf-binary</userinput>
ELF binary type not known
Abort</screen>
<para>To help the &os; kernel distinguish between a &os;
- ELF binary and a &linux; binary, use &man.brandelf.1;:</para>
+ <acronym>ELF</acronym> binary and a &linux; binary, use &man.brandelf.1;:</para>
<screen>&prompt.user; <userinput>brandelf -t Linux my-linux-elf-binary</userinput></screen>
@@ -285,49 +247,44 @@ Abort</screen>
<primary>GNU toolchain</primary>
</indexterm>
<para>Since the GNU toolchain places the appropriate branding
- information into ELF binaries automatically, this step is
+ information into <acronym>ELF</acronym> binaries automatically, this step is
usually not necessary.</para>
</sect2>
<sect2>
- <title>Installing a &linux; RPM Based Application</title>
+ <title>Installing a &linux; <acronym>RPM</acronym> Based Application</title>
- <para>&os; uses its own package database to track all software
- installed from the Ports Collection. However, the &linux; RPM
- database is not supported.</para>
-
- <para>In order to install a &linux; RPM-based application, first
+ <para>In order to install a &linux; <acronym>RPM</acronym>-based application, first
install the <package>archivers/rpm2cpio</package> package or
port. Once installed,
<systemitem class="username">root</systemitem> can use this
- command to install a <filename>.rpm</filename> as
- follows:</para>
+ command to install a <filename>.rpm</filename>:</para>
<screen>&prompt.root; <userinput>cd /compat/linux</userinput>
&prompt.root; <userinput>rpm2cpio -q < /path/to/linux.archive.rpm | cpio -id</userinput></screen>
<para>If necessary, <command>brandelf</command> the installed
- ELF binaries, but <emphasis>not</emphasis> the libraries.
+ <acronym>ELF</acronym> binaries.
Note that this will prevent a clean uninstall.</para>
</sect2>
<sect2>
<title>Configuring the Hostname Resolver</title>
- <para>If DNS does not work or this error appears:</para>
+ <para>If <acronym>DNS</acronym> does not work or this error appears:</para>
<screen>resolv+: "bind" is an invalid keyword resolv+:
"hosts" is an invalid keyword</screen>
- <para>Configure
+ <para>configure
<filename>/compat/linux/etc/host.conf</filename> as
follows:</para>
<programlisting>order hosts, bind
multi on</programlisting>
- <para>This order specifies that <filename>/etc/hosts</filename>
- is searched first and DNS is searched second. When
+ <para>This specifies that <filename>/etc/hosts</filename>
+ is searched first and <acronym>DNS</acronym> is searched second. When
<filename>/compat/linux/etc/host.conf</filename> does not
exist, &linux; applications use
<filename>/etc/host.conf</filename> and complain about the
More information about the svn-doc-head
mailing list