Multiple ABI Support - Revision history

Drobbins at 05:01, 21 January 2012

2012-01-21T05:01:51Z

Drobbins at 08:12, 29 December 2011

2011-12-29T08:12:40Z

Drobbins at 01:24, 18 January 2011

2011-01-18T01:24:51Z

Drobbins: /* Core ABI: econf() */

2011-01-01T19:17:22Z

‎Core ABI: econf()

Ermo: /* Core ABI: Working Together */ Consistent terminology and markup.

2010-12-24T01:13:46Z

‎Core ABI: Working Together: Consistent terminology and markup.

Ermo: /* Core ABI: Gcc Wrapper */ Omission.

2010-12-24T01:10:07Z

‎Core ABI: Gcc Wrapper: Omission.

Ermo: /* Core ABI: Gcc Wrapper */ Slight rewording, updated markup.

2010-12-24T01:06:14Z

‎Core ABI: Gcc Wrapper: Slight rewording, updated markup.

Ermo: /* Core ABI: Working Together */ Markup tweak.

2010-12-24T01:00:28Z

‎Core ABI: Working Together: Markup tweak.

Ermo: /* Core ABI: Working Together */ Various small cleanups/tweaks.

2010-12-24T00:59:46Z

‎Core ABI: Working Together: Various small cleanups/tweaks.

Drobbins: /* Core ABI Support */

2010-12-23T05:30:14Z

‎Core ABI Support

← Older revision		Revision as of 05:01, 21 January 2012
Line 116:		Line 116:
	[[Category:Internals]]		[[Category:Internals]]
	[[Category:Portage]]		[[Category:Portage]]
−	~~[[Category:Featured]]~~

← Older revision		Revision as of 08:12, 29 December 2011
Line 116:		Line 116:
	[[Category:Internals]]		[[Category:Internals]]
	[[Category:Portage]]		[[Category:Portage]]
		+	[[Category:Featured]]

← Older revision		Revision as of 01:24, 18 January 2011
Line 115:		Line 115:

	[[Category:Internals]]		[[Category:Internals]]
		+	[[Category:Portage]]

@@ Line 11: / Line 11: @@
 ==== Core ABI: econf() ====
-Portage's <tt>econf()</tt> function has support for automatically specifying the proper <tt>--libdir=</tt> setting to <tt>configure</tt> based on settings that are found in the system profile. The algorithm is documented as "Algorithm 9" in the PMS specification. The intended purpose of automatically setting <tt>--libdir=</tt> is designed so that 64-bit libraries will be installed into /usr/lib64 on multilib systems, and 32-bit libraries will be installed into /usr/lib32 on multilib systems, rather than simply installing these libraries into /usr/lib.
+Portage's <tt>econf()</tt> function has support for automatically specifying the proper <tt>--libdir=</tt> setting to <tt>configure</tt> based on settings that are found in the system profile. The intended purpose of automatically setting <tt>--libdir=</tt> is designed so that 64-bit libraries will be installed into /usr/lib64 on multilib systems, and 32-bit libraries will be installed into /usr/lib32 on multilib systems, rather than simply installing these libraries into /usr/lib.
 While this functionality has questionable value for most normal ebuilds (since a library installed into /usr/lib will work just as well as one installed into /usr/lib64 on an amd64 multilib system,) this functionality likely comes in handy when building the app-emulation/emul-linux-x86-* binary library bundles to support 32-bit applications, as it allows the ABI to be set in the environment, and in combination with the gcc wrapper will cause 32-bit libraries to be built and installed to /usr/lib32.

@@ Line 21: / Line 21: @@
 ==== Core ABI: Working Together ====
-The algorithm used by <tt>econf()</tt> works as follows: A system profile (or the user, via the environment) sets the ABI variable to a value like <tt>amd64</tt> or <tt>x86</tt>. A corresponding ABI-specific variable named <tt>LIBDIR_$ABI</tt> (e.g. <tt>LIBDIR_x86</tt>) will be used from the system profile, and will be set to either <tt>lib32</tt>, <tt>lib64</tt> or <tt>lib</tt>. This will be used to define the target <tt>--libdir</tt> setting used by <tt>econf()</tt>. This will allow the system profile to control exactly where libraries are installed when building them for a particular ABI, as long as the ebuild author uses <tt>econf()</tt> (part of core Portage) or <tt>get_libdir()</tt> (part of <tt>multilib.eclass</tt>.)
+The algorithm used by <tt>econf()</tt> works as follows: A system profile (or the user, via the environment) sets the <tt>ABI</tt> variable to a value like <tt>amd64</tt> or <tt>x86</tt>. A corresponding ABI-specific variable named <tt>LIBDIR_$ABI</tt> (e.g. <tt>LIBDIR_x86</tt>) will be used from the system profile, and will be set to either <tt>lib32</tt>, <tt>lib64</tt> or <tt>lib</tt>. This will be used to define the target <tt>--libdir</tt> setting used by <tt>econf()</tt>. This will allow the system profile to control exactly where libraries are installed when building them for a particular ABI, as long as the ebuild author uses <tt>econf()</tt> (part of core Portage) or <tt>get_libdir()</tt> (part of <tt>multilib.eclass</tt>.)
-In addition, the ABI variable set in the environment will cause the gcc-wrapper to adjust the <tt>CFLAGS</tt> variable, by using <tt>CFLAGS_$ABI</tt> to tell the multilib-aware gcc to target the alternate ABI. With ABI="x86" on amd64 multilib systems, this will cause <tt>-m32</tt> to be appended to the <tt>CFLAGS</tt> variable, which will instruct gcc to produce 32-bit code.
+In addition, the <tt>ABI</tt> variable set in the environment will cause the gcc-wrapper to adjust the <tt>CFLAGS</tt> variable, by using the <tt>CFLAGS_$ABI</tt> variable to tell the multilib-aware gcc to target the alternate ABI. With <tt>ABI="x86"</tt> on amd64 multilib systems, this will cause <tt>-m32</tt> to be appended to the <tt>CFLAGS</tt> variable, which will instruct gcc to produce 32-bit code.
 ==== Core ABI: Demonstration ====

@@ Line 17: / Line 17: @@
 ==== Core ABI: Gcc Wrapper ====
-It is important to note that Gentoo Linux uses a ''gcc wrapper'' as a front-end for all calls to gcc, and this wrapper  is part of the sys-devel/gcc-config ebuild. One of the features of the wrapper is that it determines whether the <tt>ABI</tt> variable has been defined in the environment, and if it has, the wrapper will automatically ensure that the <tt>CFLAGS</tt> variable that the compiler sees is actually the <tt>CFLAGS_$ABI</tt> variable, which originates from the system profile. On amd64 multilib systems, this means that a call to <tt>ABI="x86" gcc</tt> will result in an extra <tt>-m32</tt> option being passed to gcc to force it to produce 32-bit code. The <tt>-m32</tt> option will generally not appear in the build log, which cause some confusion for developers. This is a critical component of the multiple ABI support in Gentoo and Funtoo Linux.
+It is important to note that Gentoo Linux uses a ''gcc wrapper'' as a front-end for all calls to gcc, and this wrapper  is part of the sys-devel/gcc-config ebuild. One of the features of the wrapper is that it determines whether the <tt>ABI</tt> variable has been defined in the environment, and if it has, the wrapper will automatically ensure that the <tt>CFLAGS</tt> variable that the compiler sees is actually the <tt>CFLAGS_$ABI</tt> variable, which originates from the system profile. On amd64 multilib systems, this means that a call to <tt>ABI="x86" gcc</tt> will result in an extra <tt>-m32</tt> option being passed to gcc to force it to produce 32-bit code. The <tt>-m32</tt> option will generally not appear in the build log, which may cause some confusion for developers. This is a critical component of the multiple ABI support in Gentoo and Funtoo Linux.
 ==== Core ABI: Working Together ====

@@ Line 7: / Line 7: @@
 Portage and some system profiles currently contain a very small set of changes so that multiple ABIs can be targeted by Portage. In addition, Gentoo's gcc "wrapper" (part of sys-devel/gcc-config) has a key feature in it to enable this multiple ABI support -- this functionality is detailed later in this section. This implements the core minimal multiple ABI functionality.
-In practice, this capability, combined with the gcc-wrapper's ABI support, can come in handy for directing Portage to build libraries for the non-default ABI, using the appropriate directories so that this ebuild can be manually installed on your system without overwriting the libraries for the default ABI. An example of this approach is documented later in this section. This support is also useful when it is necessary to build 32-bit versions of some applications that may not be compatible with 64-bit multilib systems, and also allows for the possibility of an ebuild compiling both 32-bit and 64-bit versions of certain applications when necessary.
+In practice, this capability, combined with the gcc-wrapper's ABI support, can come in handy for directing Portage to build libraries for the non-default ABI, using the appropriate directories so that the resultant .tbz2 file can be manually installed on your system without overwriting the libraries for the default ABI. An example of this approach is documented later in this section. This support is also useful when it is necessary for the ebuild to direct the system to create 32-bit versions of some applications that may not be compatible with 64-bit multilib systems, and supports the ability for the ebuild to reliably compile both 32-bit and 64-bit versions of certain applications when necessary.
 ==== Core ABI: econf() ====