Gentoo Development Guide

TOOLCHAIN-FUNCS.ECLASS

Section: portage (5)
Updated: May 2013
Index Return to Main Contents

NAME

toolchain-funcs.eclass - functions to query common info about the toolchain

DESCRIPTION

The toolchain-funcs aims to provide a complete suite of functions for gleaning useful information about the toolchain and to simplify ugly things like cross-compiling and multilib. All of this is done in such a way that you can rely on the function always returning something sane.

FUNCTIONS

tc-getAR [toolchain prefix]

Return value: name of the archiver

tc-getAS [toolchain prefix]

Return value: name of the assembler

tc-getCC [toolchain prefix]

Return value: name of the C compiler

tc-getCPP [toolchain prefix]

Return value: name of the C preprocessor

tc-getCXX [toolchain prefix]

Return value: name of the C++ compiler

tc-getLD [toolchain prefix]

Return value: name of the linker

tc-getSTRIP [toolchain prefix]

Return value: name of the strip program

tc-getNM [toolchain prefix]

Return value: name of the symbol/object thingy

tc-getRANLIB [toolchain prefix]

Return value: name of the archiver indexer

tc-getOBJCOPY [toolchain prefix]

Return value: name of the object copier

tc-getF77 [toolchain prefix]

Return value: name of the Fortran 77 compiler

tc-getFC [toolchain prefix]

Return value: name of the Fortran 90 compiler

tc-getGCJ [toolchain prefix]

Return value: name of the java compiler

tc-getPKG_CONFIG [toolchain prefix]

Return value: name of the pkg-config tool

tc-getRC [toolchain prefix]

Return value: name of the Windows resource compiler

tc-getDLLWRAP [toolchain prefix]

Return value: name of the Windows dllwrap utility

tc-getBUILD_AR [toolchain prefix]

Return value: name of the archiver for building binaries to run on the build machine

tc-getBUILD_AS [toolchain prefix]

Return value: name of the assembler for building binaries to run on the build machine

tc-getBUILD_CC [toolchain prefix]

Return value: name of the C compiler for building binaries to run on the build machine

tc-getBUILD_CPP [toolchain prefix]

Return value: name of the C preprocessor for building binaries to run on the build machine

tc-getBUILD_CXX [toolchain prefix]

Return value: name of the C++ compiler for building binaries to run on the build machine

tc-getBUILD_LD [toolchain prefix]

Return value: name of the linker for building binaries to run on the build machine

tc-getBUILD_STRIP [toolchain prefix]

Return value: name of the strip program for building binaries to run on the build machine

tc-getBUILD_NM [toolchain prefix]

Return value: name of the symbol/object thingy for building binaries to run on the build machine

tc-getBUILD_RANLIB [toolchain prefix]

Return value: name of the archiver indexer for building binaries to run on the build machine

tc-getBUILD_OBJCOPY [toolchain prefix]

Return value: name of the object copier for building binaries to run on the build machine

tc-getBUILD_PKG_CONFIG [toolchain prefix]

Return value: name of the pkg-config tool for building binaries to run on the build machine

tc-export <list of toolchain variables>

Quick way to export a bunch of compiler vars at once.

tc-is-cross-compiler

Return value: Shell true if we are using a cross-compiler, shell false otherwise

tc-is-softfloat

See if this toolchain is a softfloat based one.

The possible return values:
 - only:   the target is always softfloat (never had fpu)
 - yes:    the target should support softfloat
 - softfp: (arm specific) the target should use hardfloat insns, but softfloat calling convention
 - no:     the target doesn't support softfloat

This allows us to react differently where packages accept softfloat flags in the case where support is optional, but rejects softfloat flags where the target always lacks an fpu.

tc-is-static-only

Return shell true if the target does not support shared libs, shell false otherwise.

tc-export_build_env [compiler variables]

Export common build related compiler settings.

econf_build [econf flags]

Sometimes we need to locally build up some tools to run on CBUILD because the package has helper utils which are compiled+executed when compiling. This won't work when cross-compiling as the CHOST is set to a target which we cannot natively execute.

For example, the python package will build up a local python binary using a portable build system (configure+make), but then use that binary to run local python scripts to build up other components of the overall python. We cannot rely on the python binary in $PATH as that often times will be a different version, or not even installed in the first place. Instead, we compile the code in a different directory to run on CBUILD, and then use that binary when compiling the main package to run on CHOST.

For example, with newer EAPIs, you'd do something like:

src_configure() {
        ECONF_SOURCE=${S}
        if tc-is-cross-compiler ; then
                mkdir "${WORKDIR}"/${CBUILD}
                pushd "${WORKDIR}"/${CBUILD} >/dev/null
                econf_build --disable-some-unused-stuff
                popd >/dev/null
        fi
        ... normal build paths ...
}
src_compile() {
        if tc-is-cross-compiler ; then
                pushd "${WORKDIR}"/${CBUILD} >/dev/null
                emake one-or-two-build-tools
                ln/mv build-tools to normal build paths in ${S}/
                popd >/dev/null
        fi
        ... normal build paths ...
}

tc-has-openmp [toolchain prefix]

See if the toolchain supports OpenMP.

tc-has-tls [-s|-c|-l] [toolchain prefix]

See if the toolchain supports thread local storage (TLS). Use -s to test the compiler, -c to also test the assembler, and -l to also test the C library (the default).

tc-arch-kernel [toolchain prefix]

Return value: name of the kernel arch according to the compiler target

tc-arch [toolchain prefix]

Return value: name of the portage arch according to the compiler target

gcc-fullversion

Return value: compiler version (major.minor.micro: [3.4.6])

gcc-version

Return value: compiler version (major.minor: [3.4].6)

gcc-major-version

Return value: major compiler version (major: [3].4.6)

gcc-minor-version

Return value: minor compiler version (minor: 3.[4].6)

gcc-micro-version

Return value: micro compiler version (micro: 3.4.[6])

gen_usr_ldscript [-a] <list of libs to create linker scripts for>

This function generate linker scripts in /usr/lib for dynamic libs in /lib. This is to fix linking problems when you have the .so in /lib, and the .a in /usr/lib. What happens is that in some cases when linking dynamic, the .a in /usr/lib is used instead of the .so in /lib due to gcc/libtool tweaking ld's library search path. This causes many builds to fail. See bug #4411 for more info.

Note that you should in general use the unversioned name of the library (libfoo.so), as ldconfig should usually update it correctly to point to the latest version of the library present.

MAINTAINERS

Toolchain Ninjas <toolchain@gentoo.org>

REPORTING BUGS

Please report bugs via http://bugs.gentoo.org/

FILES

/usr/portage/eclass/toolchain-funcs.eclass

This document was created by man2html, using the manual pages.
Time: 03:25:01 GMT, May 22, 2013