Building a Package

The emake function should be used to call make. This will ensure that the user's MAKEOPTS are used correctly. The emake function passes on any arguments provided, so it can be used to make non-default targets (emake extras), for example. Occasionally you might encounter a screwy non-autotools Makefile that explodes with emake, but this is rare.

Builds should be tested with various -j settings in MAKEOPTS to ensure that the build parallelises properly. If a package does not parallelise cleanly, it should be patched.

If patching really isn't an option, emake -j1 should be used. However, when doing this please remember that you are seriously hurting build times for many non-x86 users in particular. Forcing a -j1 can increase build times from a few minutes to an hour on some MIPS and SPARC systems.

Fixing Compiler Usage

Sometimes a package will try to use a bizarre compiler, or will need to be told which compiler to use. In these situations, the tc-getCC() function from toolchain-funcs.eclass should be used. Other similar functions are available — these are documented in man toolchain-funcs.eclass.

Sometimes a package will not use the user's ${CFLAGS} or ${LDFLAGS}. This must be worked around, as sometimes these variables are used for specifying critical ABI options. In these cases, the build scripts should be modified (for example, with sed) to use ${CFLAGS} or ${LDFLAGS} correctly.

inherit flag-o-matic toolchain-funcs

src_compile() {
	# -Os not happy
	replace-flags -Os -O2

	# We have a weird to work with which ignores our
	# compiler preferences. yay!
	sed -i -e "s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}:" \
		|| die "sed fix failed. Uh-oh..."
	./ || die "Build failed!"

Portage performs a QA check which verifies if LDFLAGS are respected. This QA check is enabled only when LDFLAGS variable contains -Wl,--hash-style=gnu. (This flag can be used only on systems which use sys-libs/glibc except for machines with a MIPS CPU.)