diff options
Diffstat (limited to 'archs/amd64/text.xml')
| -rw-r--r-- | archs/amd64/text.xml | 265 |
1 files changed, 83 insertions, 182 deletions
diff --git a/archs/amd64/text.xml b/archs/amd64/text.xml index e4713f5..05cce5f 100644 --- a/archs/amd64/text.xml +++ b/archs/amd64/text.xml @@ -1,10 +1,10 @@ -<?xml version="1.0"?> +<?xml version="1.0" encoding="UTF-8"?> <guide self="archs/amd64/"> <chapter> -<title>Arch Specific Notes — AMD64/EM64T</title> +<title>Arch specific notes — AMD64/EM64T</title> <section> -<title>Position Independent Code Issues</title> +<title>Position Independent Code issues</title> <body> <p> @@ -69,8 +69,9 @@ doesn't help upstream at all. <p> Another bad idea is to (ab)use <c>append-flags</c> function from -<c>flag-o-matic.eclass</c>. Applying <c>-fPIC</c> on all objects should not be -done. It should only be applied to shared objects. +<c><uri link="::eclass-reference/flag-o-matic.eclass/"/></c>. +Applying <c>-fPIC</c> on all objects should not be done. It should only be +applied to shared objects. </p> </body> @@ -82,32 +83,33 @@ done. It should only be applied to shared objects. <body> <p> -The current AMD64 processors are able to natively run 32bit code on a 64bit +The current AMD64 processors are able to natively run 32-bit code on a 64-bit kernel. Therefore, you can run programs compiled for x86 in an amd64 environment. -However, 32bit applications need to be linked against 32bit libraries. Mixing -them won't work. For this reason the libraries are sorted, 32bit libraries normally -go to <c>/lib32</c> respectively <c>/usr/lib32</c>, the 64bit ones normally to <c>/lib64</c> or -<c>/usr/lib64</c>. In a perfect world, you wouldn't have to read on. Unfortunately, -that's not the case, and so it's a bit more complicated. +However, 32-bit applications need to be linked against 32-bit libraries. Mixing +them won't work. For this reason the libraries are sorted, 32-bit libraries +normally go to <c>/lib32</c> respectively <c>/usr/lib32</c>, the 64-bit ones +normally to <c>/lib64</c> or <c>/usr/lib64</c>. In a perfect world, you wouldn't +have to read on. Unfortunately, that's not the case, and so it's a bit more +complicated. </p> </body> <subsection> -<title>Multilib-Toolchain</title> +<title>Multilib toolchain</title> <subsubsection> <title>GCC</title> <body> <p> -To generate 32bit code, we need a multilib-capable GCC. On other architectures, +To generate 32-bit code, we need a multilib-capable GCC. On other architectures, this functionality is enabled with the USE flag <c>multilib</c>. This is also true for amd64 with the <e>pre</e>-2005.0 profiles. From 2005.0 on, you have to choose whether you want multilib support or not by selecting the profile. Choose <c>2005.0/no-multilib</c> if you don't want it, all other profiles have the <c>multilib</c> USE flag masked, you're forced to it. With these profiles, GCC will produce x86-code whenever you add <c>-m32</c> to its command line. Adding <c>-m64</c> -or omitting any bit-width option will default to producing 64bit code. +or omitting any bit-width option will default to producing 64-bit code. </p> </body> @@ -118,10 +120,10 @@ or omitting any bit-width option will default to producing 64bit code. <body> <p> -If you've chosen a multilib profile, glibc will be built twice, once 64bit and -once 32bit. This is because nearly every application links against glibc. +If you've chosen a multilib profile, glibc will be built twice, once 64-bit and +once 32-bit. This is because nearly every application links against glibc. To understand how this is done in the ebuild, read -<uri link="::archs/amd64/#The ABI Variable"/>. +<uri link="::archs/amd64/#The ABI variable"/>. </p> </body> @@ -129,180 +131,93 @@ To understand how this is done in the ebuild, read </subsection> <subsection> -<title>The <c>emul-linux-x86-*</c> packages</title> +<title>32-bit compatibility</title> <body> <p> -As you read above, 32bit applications must be linked against 32bit libraries. -For that, we've put together the most used libraries and stuck them into the -so-called <c>emul-linux-x86</c> packages, which are located in the -<c>app-emulation</c> category. The current list of all the <c>emul-linux-x86</c> -packages, can be found <uri link="https://dev.gentoo.org/~pacho/emul.html">here.</uri> +As you read above, 32-bit applications must be linked against 32-bit libraries. +For that, we've made the most common libraries as multilib (via <c>ABI</c> +variable and <c><uri link="::eclass-reference/multilib.eclass/"/></c>). </p> -<p> -These packages only provide pre-compiled libraries. Currently, the -archives are assembled manually, which is the main reason to keep the packages -as tidy as possible. Do not include libraries that aren't commonly used. -</p> - -<note> - The emul-packages might conflict with their native images, but only in - uncritical locations like <c>/usr/share</c> which are arch-independent anyway. -</note> - </body> </subsection> <subsection> -<title><c>Libdir</c> Links</title> +<title>Libdir links</title> <body> <p> -Currently, we provide several profiles, each with its own combination of <c>libdir</c> -configurations. +Currently, we provide several profiles, each with its own combination of +<c>libdir</c> configurations. Table entries x86, amd64, etc. indicate that +the directory contains objects for this ABI; entries with an arrow indicate +a symlink to the respective directory. </p> <table> <tr> - <th> - Profile - </th> - <th> - lib32 - </th> - <th> - lib - </th> - <th> - lib64 - </th> + <th>Profile</th> + <th>lib</th> + <th>lib32</th> + <th>lib64</th> + <th>libx32</th> </tr> <tr> - <ti> - 2004.3 - </ti> - <ti> - *l->emul* - </ti> - <ti> - d64 - </ti> - <ti> - *l->lib* - </ti> + <ti>17.0</ti> + <ti>-> lib64</ti> + <ti>x86</ti> + <ti>amd64</ti> + <ti>non-existent</ti> </tr> <tr> - <ti> - 2004.3/lib64 - </ti> - <ti> - *l->emul* - </ti> - <ti> - *l->64* - </ti> - <ti> - d64 - </ti> + <ti>17.0/no-multilib</ti> + <ti>-> lib64</ti> + <ti>non-existent</ti> + <ti>amd64</ti> + <ti>non-existent</ti> </tr> <tr> - <ti> - >=2005.0 - </ti> - <ti> - d32 - </ti> - <ti> - *l->64* - </ti> - <ti> - d64 - </ti> + <ti>17.0/x32</ti> + <ti>-> libx32</ti> + <ti>x86</ti> + <ti>amd64</ti> + <ti>x32</ti> </tr> <tr> - <ti> - >=2005.0/no-multilib - </ti> - <ti> - d32 - </ti> - <ti> - *l->64* - </ti> - <ti> - d64 - </ti> - </tr> - <tr> - <ti> - >=2005.0/no-symlink - </ti> - <ti> - d32 - </ti> - <ti> - d - </ti> - <ti> - d64 - </ti> + <ti>17.1</ti> + <ti>x86</ti> + <ti>non-existent</ti> + <ti>amd64</ti> + <ti>non-existent</ti> </tr> <tr> - <ti> - >=2005.0/no-symlink/no-lib32 - </ti> - <ti> - inexistant - </ti> - <ti> - d32 - </ti> - <ti> - d64 - </ti> + <ti>17.1/no-multilib</ti> + <ti>n/a</ti> + <ti>non-existent</ti> + <ti>amd64</ti> + <ti>non-existent</ti> </tr> </table> -<dl> - <dt> - d - </dt> - <dd> - Directory containing mixed-bit objects - </dd> - <dt> - dXX - </dt> - <dd> - Directory containing XXbit objects - </dd> - <dt> - l->foo - </dt> - <dd> - Link to foo - </dd> -</dl> - <p> -To always get the right path, you should use the function <c>$(get_libdir)</c> from -<c>multilib.eclass</c>. It will always return the correct directory, on all arches. -And of course it also takes care of the <c>ABI</c> variable. +To always get the right path, you should use <c>$(get_libdir)</c> which is +available as a package manager function since EAPI 6. It will always return +the correct directory, on all arches. And of course it also takes care of +the <c>ABI</c> variable. </p> </body> </subsection> <subsection> -<title>The <c>multilib-strict</c> Feature</title> +<title>The <c>multilib-strict</c> feature</title> <body> <p> Many Makefiles assume that their libraries should go to <c>/usr/lib</c>, or <c>$(prefix)/lib</c>. This assumption can cause a serious mess if <c>/usr/lib</c> -isn't a symlink to <c>/usr/lib64</c>. To find the bad packages, we have a portage feature -called <b>multilib-strict</b>. It will prevent emerge from putting 64bit libraries +isn't a symlink to <c>/usr/lib64</c>. To find the bad packages, we have a Portage feature +called <b>multilib-strict</b>. It will prevent emerge from putting 64-bit libraries into anything other than <c>(/usr)/lib64</c>. </p> @@ -318,25 +233,10 @@ this behaviour is controlled by the <c>MULTILIB_STRICT_EXEMPT</c> variable in <body> <p> -In most cases, it's sufficient to use the <c>$(get_libdir)</c> function from -<c>multilib.eclass</c>: +In most cases, default <c>econf</c> behaviour is sufficient, because it will +pass the correct <c>--libdir</c> option to <c>configure</c>. </p> -<codesample lang="ebuild"> -inherit multilib - -src_compile() { - econf \ - --libdir=/usr/$(get_libdir) - - emake || die -} - -src_install() { - emake DESTDIR="${D}" install || die -} -</codesample> - <p> Some packages provide really bad Makefiles which hard-code <c>/usr/lib</c>. Those should be <c>sed</c> -ed or patched. Don't forget to let upstream know about your @@ -348,13 +248,13 @@ modifications! </subsection> <subsection> -<title>Headers and Multilib</title> +<title>Headers and multilib</title> <body> <p> Most C/C++ programs need standard header files like <c>types.h</c>. Some of them depend on architecture specific facts, e.g. <c>types.h</c> on the length -of machine words. To ensure that we can compile both 32bit and 64bit +of machine words. To ensure that we can compile both 32-bit and 64-bit applications and libraries, we treat <c>/usr/include/asm</c> a bit special. </p> @@ -377,25 +277,26 @@ This is what <c>/usr/include/asm/types.h</c> looks like on an AMD64 box: As you can see, this is just a wrapper that decides which file you need depending on the parameter <c>-D</c> given to gcc. You'll probably run into some troubles if you try to compile something by hand and forget to append -<c>-D__x86_64__</c> to your <c>CFLAGS</c>. Of course, this is <b>not necessary</b> when -using portage. For an explanation, see the <uri link="::archs/amd64/#The ABI Variable"/> -section. +<c>-D__x86_64__</c> to your <c>CFLAGS</c>. Of course, this is +<b>not necessary</b> when using Portage. For an explanation, see the +<uri link="::archs/amd64/#The ABI variable"/> section. </p> </body> </subsection> <subsection> -<title>The ABI Variable</title> +<title>The ABI variable</title> <body> <p> -Whenever portage builds something on amd64, it has to decide whether it should -be 32bit or 64bit. As stated in <uri link="::archs/amd64/#Headers and Multilib"/> -the <c>__i386__</c> or <c>__x86_64__</c> respectively, is needed in <c>CDEFINE</c>. -Also, gcc has to know what code it should produce, therefore <c>-m32</c> or <c>-m64</c> -must be appended to CFLAGS. This is done via <c>profile.bashrc</c>. All you need to do -if you want to build a package 32bit is to set <c>ABI=x86</c>. +Whenever Portage builds something on amd64, it has to decide whether it should +be 32-bit or 64-bit. As stated in +<uri link="::archs/amd64/#Headers and multilib"/> the <c>__i386__</c> or +<c>__x86_64__</c> respectively, is needed in <c>CDEFINE</c>. Also, gcc has to +know what code it should produce, therefore <c>-m32</c> or <c>-m64</c> must be +appended to CFLAGS. This is done via <c>profile.bashrc</c>. All you need to do +if you want to build a package 32-bit is to set <c>ABI=x86</c>. </p> <p> @@ -424,10 +325,10 @@ LIBDIR_x86="lib32" </section> <section> -<title>Porting Notes</title> +<title>Porting notes</title> <subsection> -<title>Machine Word sizes</title> +<title>Machine word sizes</title> <body> <p> @@ -574,7 +475,7 @@ segmentation faults or strange behaviour. GCC 4.0 refuses to compile such code. </section> <section> -<title>Other Resources</title> +<title>Other resources</title> <body> <ul> |