Difference between pages "Multiple ABI Support" and "Package:KDE (metapackage)"

(Difference between pages)
(Add a warning to indicate outdated information)
 
m (more formatting)
 
Line 1: Line 1:
{{warning|The instructions below seem outdated (as of 2014-12-01). More recent information seems to be present on the gentoo wiki at http://wiki.gentoo.org/wiki/Project:Multilib/Concepts}}
+
{{Ebuild
 +
|Summary=KDE - merge this to pull in all split kde-base/* packages
 +
|CatPkg=kde-base/kde-meta
 +
|Maintainer=
 +
}}
 +
{{PageNeedsUpdates}}
  
=== Summary ===
+
==Introduction==
 +
* The KDE Plasma Desktop 4.x
 +
* KDE Software Compilation
  
Support for multiple ABIs has been partially integrated into Portage and the Gentoo gcc wrapper (part of sys-devel/gcc-config) and has been enabled in some system profiles. Extended Multiple ABI is available as part of <tt>multilib.eclass</tt>. This page documents this functionality so it can be more easily understood, used and improved.
+
==Prerequisites==
 +
=== Profile Configuration ===
 +
<console>###i## sudo eselect profile add funtoo/1.0/linux-gnu/mix-ins/kde</console>
  
=== Core ABI Support ===
+
* X11 server, policykit, consolekit, udisks, etc.
  
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.
+
==Installation==
 +
===emerge ===
 +
<console>###i## emerge kde-base/kde-meta</console>
 +
<br />
 +
* configuration
 +
<br />
 +
* Start KDE Plasma Desktop
 +
<br />
 +
<console>
 +
###i##rc-service xdm start
 +
</console>
  
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.
+
==First Steps==
 
+
* Additional configuration
==== Core ABI: econf() ====
+
* 'Add-in' software
 
+
{{EbuildFooter}}
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.
+
 
+
==== 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 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 ====
+
 
+
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 <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 ====
+
 
+
To test the multiple ABI functionality on an amd64 multilib system, you can execute the following command:
+
 
+
<pre>
+
# ABI="x86" emerge --buildpkgonly sys-libs/zlib
+
</pre>
+
 
+
If you compare the libz shared library in the resultant .tbz2 package ot the one installed in /lib64, you'll note that the one in the .tbz2 is 32-bit while the one in /lib64 is 64-bit:
+
 
+
<pre>
+
ninja1 lib32 # file libz.so.1.2.5
+
libz.so.1.2.5: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
+
ninja1 lib32 # file /lib/libz.so.1.2.5
+
/lib/libz.so.1.2.5: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
+
</pre>
+
 
+
It is important to note that Gentoo's gcc wrapper (part of sys-devel/gcc-config) instructs gcc to produce 32-bit code by silently passing (not visible in the build output, due to the wrapper design)a <tt>-m32</tt> option to all compiler calls.
+
 
+
Note that you should not install the 32-bit zlib .tbz2 package on a 64-bit multilib system, as it will replace the critical 64-bit zlib binaries on your system. Portage's  /var/db/pkg database does not allow side-by-side installations of packages that were built against different ABIs. However, this Portage functionality can be used to build 32-bit libraries when needed, which can be installed via manual extraction of the resultant .tbz2 file to the root filesystem.
+
 
+
=== Extended ABI Support ===
+
 
+
Beyond the core functionality, the <tt>multilib.eclass</tt> (which is inherited as part of the ubiquitous <tt>eutils.eclass</tt>) contains a more significant set of code to support multiple ABIs, which appears to be designed to be eventually merged into the Portage core. This means that latent multiple ABI support is available in Portage and can be used without inheriting <tt>multilib.eclass</tt> for "regular" ebuilds, but ebuilds that need more control over the ABI configuration can inherit <tt>multilib.eclass</tt> for access to a significant number of helper functions. If you want to use <tt>multilib.eclass</tt>, first familiarize yourself with the changes in Portage that exist that support <tt>multilib.eclass</tt> functionality, which are documented in this section. Then you will have a much easier time understanding <tt>multilib.eclass</tt>.
+
 
+
==== ABI Profile Variables ====
+
 
+
The following variables are supported on a limited number of architectures - namely, those that have different ABIs available. These include Sparc, PowerPC and PC-compatible x86/amd64 architectures.
+
+
; ABI
+
: Defines the name of the current ABI for which packages should be built. This variable is recognized by the gcc wrapper - see "Core gcc wrapper ABI support", below.
+
 
+
; DEFAULT_ABI
+
: Defines the name of the default ABI for which packages should be built.
+
 
+
; MULTILIB_ABIS
+
: This consists of a space-separated string of one or more ABIs that are supported on the current system. Amd64 multilib systems will have this set to <tt>amd64 x86</tt>
+
 
+
==== ABI-Specific Profile Variables ====
+
 
+
These variables have a suffix (represented below by <tt>*</tt>) that is set based on the ABI that the particular setting is for. For example, <tt>LIBDIR_amd64</tt> would set the library directory name for the amd64 ABI. The rationale for this naming convention is that it allows settings for multiple architectures to be defined together in a single file, and multiple ABI settings to exist on a system that may support multiple ABIs.
+
 
+
; LIBDIR_*
+
 
+
; CHOST_*
+
 
+
; CDEFINE_*
+
 
+
; CFLAGS_*
+
: Note: this variable is used by the gcc wrapper when ABI is defined in the environment.
+
 
+
; LDFLAGS_*
+
 
+
; ASFLAGS_*
+
 
+
==== multilib.eclass ====
+
 
+
Note that a number of these functions can probably be replaced with enhanced profile settings, as all they do is spit out canned values based on the setting of one variable or another. They are also prime candidates for inclusion into the Portage core, possibly with some reworking or deprecation so that as many of these as possible are replaced with "dead" variables rather than "live" code.
+
 
+
; has_multilib_profile()
+
: This is a boolean function that returns 0 (true) if multiple ABIs are defined in the MULTILIB_ABIS variable; otherwise 1 (false).
+
 
+
; get_libdir()
+
: Returns the "lib" directory name to use, based on the current setting of ABI. For example, on amd64 multilib systems, this will typically return <tt>lib64</tt>, and is typically used in <tt>src_configure()</tt> like this: <tt>./configure --libdir=/usr/$(get_libdir)</tt>.
+
 
+
; get_modname()
+
: Used by some ebuilds that generate dynamically-loadable modules, called "bundles" on MacOS X. ELF (used by Linux) makes no differentiation between the handling of shared libraries and loadable modules (or their file extension, which is ".so",) but Mach (MacOS X) does. MacOS X bundles cannot be linked against, but can be dynamically loaded using the dyld API. Apple also recommends that they have an extension of ".bundle" rather than ".so". This function will return ".bundle" for Darwin (Mach) systems, and ".so" for everything else. For more information, see [http://docstore.mik.ua/orelly/unix3/mac/ch05_03.htm MacOS X Guide For Unix Geeks].
+
 
+
; get_libname()
+
: Used by a handful of ebuilds to determine the proper suffix for shared libraries on the current system. This function has various hard-coded values depending on the value of CHOST. For example, Darwin systems will get an echoed value of "<tt>.dylib</tt>" while Linux systems will get a value of "<tt>.so</tt>". Accepts an optional version argument that will be properly appended to the output.
+
 
+
; multilib_env()
+
: Used by toolchain.eclass, gnatbuild.eclass and the glibc ebuild - sets up environment variables for using a cross-compiler. Accepts a single argument - the target architecture in GNU format.
+
 
+
; multilib_toolchain_setup()
+
: In practice, this function is used exclusively to target a non-default x86 ABI on amd64 multilib systems. It accepts one argument, the name of an ABI, or <tt>default</tt> as a shorthand for the default system ABI. It will configure environment variables so the x86 (or other) compiler is targeted, and also backs up all modified variables so they can be restored later. It is typically used to allow non-64-bit-compatible code to still be installed on amd64 multilib systems, by adding the following to the top of <tt>src_configure()</tt>:
+
 
+
<pre>
+
src_configure() {
+
  use amd64 && multilib_toolchain_setup x86
+
  # we're now building a 32-bit app on a 64-bit system, whee!
+
  econf
+
}
+
</pre>
+
 
+
=== ABI Support Limitations ===
+
 
+
Only a handful of applications leverage the more sophisticated functionality available in <tt>multilib.eclass</tt>, and Gentoo Linux currently uses binary bundles of 32-bit libraries to provide support for 32-bit applications on 64-bit multilib systems, rather than using Portage functionality to build these components from source. One possible explanation for this approach is that Portage currently does not allow applications to be slotted on ABI -- that is, a 32-bit and 64-bit version of sys-libs/zlib cannot co-exist in the Portage /var/db/pkg database, even if they do not overwrite one another on the filesystem when installed. There may be other possible reasons why building 32-bit packages from source remains unfeasible in Gentoo Linux, and will be documented here as they are discovered.
+
 
+
[[Category:Internals]]
+
[[Category:Portage]]
+
[[Category:Official Documentation]]
+

Revision as of 21:06, December 6, 2014

kde-base/kde-meta


Source Repository:Funtoo Overlay

Summary: KDE - merge this to pull in all split kde-base/* packages

Use Flags

kdepim
Pull in KDE PIM
sdk
Pull in developer-specific meta-packages

KDE (metapackage)


Introduction

  • The KDE Plasma Desktop 4.x
  • KDE Software Compilation

Prerequisites

Profile Configuration

# sudo eselect profile add funtoo/1.0/linux-gnu/mix-ins/kde
  • X11 server, policykit, consolekit, udisks, etc.

Installation

emerge

# emerge kde-base/kde-meta


  • configuration


  • Start KDE Plasma Desktop


#rc-service xdm start

First Steps

  • Additional configuration
  • 'Add-in' software