1 |
On Mon, Sep 10, 2018 at 01:46:51AM +0200, Chí-Thanh Christopher Nguyễn wrote: |
2 |
> Michał Górny schrieb: |
3 |
> > Are you suggesting that |
4 |
> > upstream is going to detect all those situations and prevent them from |
5 |
> > occurring, or are you going to WONTFIX the resulting bugs? |
6 |
> |
7 |
> No. With -Werror, upstream indicates that if a warning occurs, the build |
8 |
> should fail and the resulting code not be installed on user systems. |
9 |
> |
10 |
> Instead, someone knowledgeable should look at the situation *first* and |
11 |
> determine whether it is a bogus warning, a trivial issue, or something which |
12 |
> warrants further attention. |
13 |
> |
14 |
> I have long disagreed with QA policy on this, and think that ebuilds should |
15 |
> respect upstream here. Of course giving users the ability to override. |
16 |
|
17 |
I disagree. -Werror means that upstream wants it to build without |
18 |
warnings on their distro with their version of the compiler with their |
19 |
versions of all the libraries. Even if upstream was using gentoo |
20 |
(they're not) they'd need to be testing both stable and unstable |
21 |
toolchains since there are frequently warnings that show up in one and |
22 |
not the other and also between gcc/clang. |
23 |
|
24 |
I agree with jer on this, if you want specific warnings to be errors use |
25 |
-Werror=foo or something not a blanket -Werror. |
26 |
|
27 |
There are things that upstream absolutely should be setting which make a |
28 |
big difference for security like FORTIFY_SOURCE but hardened already has |
29 |
that set so I get this and thus basically everything would fail to |
30 |
compile. |
31 |
|
32 |
$ gcc -O1 -D_FORTIFY_SOURCE=2 foo.c |
33 |
<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined |
34 |
<built-in>: note: this is the location of the previous definition |
35 |
|
36 |
This all on amd64 too. If we start with other arches or cross compilers |
37 |
or other things then -Werror is just not possible. |
38 |
|
39 |
-- Jason |