|
Line
Link Here
|
| 0 |
-- ebuild-writing/common-mistakes/text.xml |
0 |
++ ebuild-writing/common-mistakes/text.xml |
|
Lines 94-99
Link Here
|
| 94 |
</subsection> |
94 |
</subsection> |
| 95 |
|
95 |
|
| 96 |
<subsection> |
96 |
<subsection> |
|
|
97 |
<title>-Werror compiler flag not removed</title> |
| 98 |
<body> |
| 99 |
"-Werror" is a flag which turns all warnings into errors and thus will abort compiling if any warning is encountered. |
| 100 |
|
| 101 |
<p><b>Rationale</b><p /> |
| 102 |
This flag is not recommended for releases and should always be disabled when encountered in build-logs, because there are numerous cases where this breaks without purpose, e.g.: |
| 103 |
<ul> |
| 104 |
<li> |
| 105 |
new warnings on version bumps of GCC/GLIBC the developer was not aware of at the point of coding |
| 106 |
</li> |
| 107 |
<li> |
| 108 |
some autoconf checks will fail badly |
| 109 |
</li> |
| 110 |
<li> |
| 111 |
libraries adding deprecated API warnings although that API is still working/supported |
| 112 |
</li> |
| 113 |
<li> |
| 114 |
on less known architectures we may get different/more warnings than on common ones |
| 115 |
</li> |
| 116 |
<li> |
| 117 |
random breakage depending on what distro/architecture/library version/kernel/userland the developer was testing "-Werror" on |
| 118 |
</li> |
| 119 |
</ul> |
| 120 |
Turning off "-Werror" we will still see the warnings, but there is no reason that they cause compile failure. Also note that portage already emits QA notices about gcc warnings that can cause runtime breakage. |
| 121 |
</p> |
| 122 |
|
| 123 |
<p><b>How to fix</b><p /> |
| 124 |
To fix the affected build system you should try the following methods: |
| 125 |
<ul> |
| 126 |
<li> |
| 127 |
remove the compiler flag from the build system, <e>e.g. Makefile.am or configure.ac</e> or even provide a switch (for autotools based build systems that could be "--disable-werror", which is good for sending a patch upstream) |
| 128 |
</li> |
| 129 |
<li> |
| 130 |
use <e>append-flags -Wno-error</e> (needs flag-o-matic.eclass); for this to work the environment flags have to be respected and placed after build system flags; this method is not preferred as it will disable all "-Werror=specific-warning" flags as well, see next section |
| 131 |
</li> |
| 132 |
</ul> |
| 133 |
Always check that it's really gone in the build log. |
| 134 |
</p> |
| 135 |
|
| 136 |
<p><b>Specific -Werror=... flags</b><p /> |
| 137 |
GCC can turn any specific warning into an error. A specific -Werror flag would be "-Werror=implicit-function-declaration" for example and will only affect warnings about implicit function declarations. It's mostly safe to leave these untouched, cause they are pinned to this issue and should not cause random build time breakage. Also, we can expect that upstream did this on purpose to avoid known runtime errors and not just for testing their builds. However you should check the specified warnings yourself or ask other developers if unsure. |
| 138 |
</p> |
| 139 |
|
| 140 |
<p><b>Exceptions</b><p /> |
| 141 |
Removing "-Werror" from configure.ac can cause breakage in very rare cases where the configure phase relies on the exit code. See <uri link="http://sourceforge.net/tracker/?func=detail&aid=2959749&group_id=204462&atid=989708">app-emulation/open-vm-tools bug</uri>. But even then we remove it from the resulting Makefile. |
| 142 |
</p> |
| 143 |
</body> |
| 144 |
</subsection> |
| 145 |
|
| 146 |
<subsection> |
| 97 |
<title>Missing/Invalid/Broken Header</title> |
147 |
<title>Missing/Invalid/Broken Header</title> |
| 98 |
<body> |
148 |
<body> |
| 99 |
|
149 |
|
