
jolsa at redhat
May 4, 2012, 8:26 AM
Post #9 of 12
(56 views)
Permalink
|
|
Re: [patch] perf: Fix build failure on OpenSuse userspace
[In reply to]
|
|
On Fri, May 04, 2012 at 12:10:55PM -0300, Lucas De Marchi wrote: > On Fri, May 4, 2012 at 4:09 AM, Ingo Molnar <mingo [at] kernel> wrote: > > > > * Greg KH <gregkh [at] linuxfoundation> wrote: > > > >> On Thu, May 03, 2012 at 11:01:54PM -0400, Arnaud Lacombe wrote: > >> > Hi, > >> > > >> > On Thu, May 3, 2012 at 10:47 PM, Greg KH <gregkh [at] linuxfoundation> wrote: > >> > > On Thu, May 03, 2012 at 10:35:02PM -0400, Arnaud Lacombe wrote: > >> > >> Hi, > >> > >> > >> > >> On Thu, May 3, 2012 at 10:29 PM, Arnaud Lacombe <lacombar [at] gmail> wrote: > >> > >> > [...] > >> > >> > [0]: http://pkgs.fedoraproject.org/gitweb/?p=flex.git;a=blob;f=flex-2.5.35-hardening.patch;h=7d608ea2371fa3295bdb8eb97c15eeb03029c02b;hb=HEAD > >> > >> > > >> > >> as a side note, this patch sounds more being about "silencing" than > >> > >> "hardening"... > >> > > > >> > > That's nice, but I can build the perf version in 3.3 just fine, so > >> > > something broke here (hint, build regression.) Do I have to bisect it > >> > > down to find the problem? > >> > > > >> > there is most likely nothing to bisect, `perf' seems to have never > >> > required any parser before 3.4. The way the rest of the tools > >> > (especially `kconfig', `genksyms' and `dtc') manage parsers is via > >> > pre-generated .[ch]_shipped version of the lexer/tokenizer. It's been > >> > working well for a long time as such. `perf' will certainly have to > >> > follow the same path. > >> > >> Well, it can allow bison to run, but just don't break the build if the > >> generated code it creates happens to contain warnings. > >> > >> I'm using bison 2.5 and flex 2.5.35, and my phone number is... > >> > >> Like this really matters? This needs to work for everyone, if not, you > >> better put the specific version numbers you need to require in the > >> Documentation/Changes file. > >> > >> So, how do I fix this? > > > > Does the (untested) patch below help? > > > > If not then please paste me the build failure output (it will > > most likely change due to the patch), and until we fix this > > build regression on OpenSuse userspace you can work it around > > via: > > > > make WERROR=0 > > > > Thanks, > > > > Ingo > > > > diff --git a/tools/perf/Makefile b/tools/perf/Makefile > > index 7055a00..3174e9b 100644 > > --- a/tools/perf/Makefile > > +++ b/tools/perf/Makefile > > @@ -729,10 +729,10 @@ $(OUTPUT)perf.o perf.spec \ > > # over the general rule for .o > > > > $(OUTPUT)util/%-flex.o: $(OUTPUT)util/%-flex.c $(OUTPUT)PERF-CFLAGS > > - $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) -Iutil/ -Wno-redundant-decls -Wno-switch-default -Wno-unused-function $< > > + $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) -Iutil/ -Wno-redundant-decls -Wno-switch-default -Wno-unused-function -Wno-unused-parameter $< > > Nah. What you need is -Wno-sign-compare. > > But you are better off overriding the CFLAGS for these generated > files. Just put -Wno-error as the last one (untested, but should work) yep, I think it's good idea.. and plus '-w' to suppres warnings not to polute the build log jirka --- diff --git a/tools/perf/Makefile b/tools/perf/Makefile index 7055a00..9c734a2 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -729,10 +729,10 @@ $(OUTPUT)perf.o perf.spec \ # over the general rule for .o $(OUTPUT)util/%-flex.o: $(OUTPUT)util/%-flex.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) -Iutil/ -Wno-redundant-decls -Wno-switch-default -Wno-unused-function $< + $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) -Iutil/ -Wno-error -w $< $(OUTPUT)util/%-bison.o: $(OUTPUT)util/%-bison.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) -DYYENABLE_NLS=0 -DYYLTYPE_IS_TRIVIAL=0 -Iutil/ -Wno-redundant-decls -Wno-switch-default -Wno-unused-function $< + $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) -DYYENABLE_NLS=0 -DYYLTYPE_IS_TRIVIAL=0 -Iutil/ -Wno-error -w $< $(OUTPUT)%.o: %.c $(OUTPUT)PERF-CFLAGS $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) $< -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo [at] vger More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|