1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
<?xml version="1.0" encoding="UTF-8"?>
<devbook self="ebuild-writing/functions/src_compile/building/">
<chapter>
<title>Building a package</title>
<body>
<p>
The <c>emake</c> function should be used to call <c>make</c>. This will ensure that
the user's <c>MAKEOPTS</c> are used correctly. The <c>emake</c> function passes on
any arguments provided, so it can be used to make non-default targets (<c>emake
extras</c>), for example. Occasionally you might encounter a screwy non-autotools
<c>Makefile</c> that explodes with <c>emake</c>, but this is rare.
</p>
<p>
Builds should be tested with various <c>-j</c> settings in <c>MAKEOPTS</c> to ensure
that the build parallelises properly. If a package does <e>not</e> parallelise
cleanly, it should be patched.
</p>
<p>
If patching <e>really</e> isn't an option, <c>emake -j1</c> should be
used. However, when doing this, please remember that you are seriously
hurting build times for many non-x86 users in particular. Forcing
<c>-j1</c> can increase build times from a few minutes to an hour on
some MIPS and SPARC systems.
</p>
</body>
<section>
<title>Fixing compiler usage</title>
<body>
<p>
Sometimes a package will try to use a bizarre compiler, or will need to be told
which compiler to use. In these situations, the <c>tc-getCC()</c> function from
<uri link="::eclass-reference/toolchain-funcs.eclass/"/> should be used.
Other similar functions are available <d/> these are documented in
<c>man toolchain-funcs.eclass</c>.
</p>
<p>
Note that packages should always respect the user's <c>CC</c> preference
and must not rely on convenience symlinks such as <c>/usr/bin/cc</c>
or <c>/usr/bin/gcc</c>. A tracker <uri link="https://bugs.gentoo.org/243502">
bug</uri> exists to document such issues. Additional documentation exists on the
<uri link="https://wiki.gentoo.org/wiki/Project:Toolchain/use_native_symlinks">
wiki</uri>.
</p>
<note>
It is <e>not</e> correct to use the <c>${CC}</c> variable for this purpose.
</note>
<p>
Sometimes a package will not use the user's <c>${CFLAGS}</c> or <c>${LDFLAGS}</c>.
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 <c>sed</c> or via a patch) to use <c>${CFLAGS}</c> or
<c>${LDFLAGS}</c> correctly.
</p>
<codesample lang="ebuild">
inherit flag-o-matic toolchain-funcs
src_prepare() {
default
# We have a weird Makefile to work with which ignores our
# compiler preferences. yay!
# Note the single quotes (hence the delimiter is not an issue)
sed -i -e 's:cc -O2:$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS):' Makefile \
|| die "sed fix failed. Uh-oh..."
}
src_compile() {
# -Os not happy
replace-flags -Os -O2
emake CC="$(tc-getCC)" \
CPPFLAGS="${CPPFLAGS}" \
CFLAGS="${CFLAGS}" \
LDFLAGS="${LDFLAGS}"
}
</codesample>
<note>
Try to not substitute the value with <c>sed</c> directly, but instead make the
build script use the variables. The variables may contain characters such as a
slash, a comma, or a colon, which are often used with <c>sed</c>, and this
would break its syntax.
</note>
<p>
Portage performs a QA check which verifies if LDFLAGS are respected. This QA check
is enabled only when <c>LDFLAGS</c> variable contains <c>-Wl,--hash-style=gnu</c>.
(This flag can be used only on systems which use <c>sys-libs/glibc</c> except for
machines with a MIPS CPU.)
</p>
</body>
</section>
</chapter>
</devbook>
|
GitWeb