On Thu, Nov 28, 2013 at 09:02:23PM +0100, Jean Pihet wrote: > On 28 November 2013 14:46, Arnaldo Carvalho de Melo <[email protected]> > wrote: > > Em Thu, Nov 28, 2013 at 09:56:19AM -0300, Arnaldo Carvalho de Melo escreveu: > >> Em Thu, Nov 28, 2013 at 10:58:01AM +0100, Jiri Olsa escreveu: > >> > On Wed, Nov 27, 2013 at 11:43:23PM +0100, Jiri Olsa wrote: > >> > > On Wed, Nov 27, 2013 at 05:16:34PM -0300, Arnaldo Carvalho de Melo > >> > > wrote: > >> > > LINK perf > >> > > /bin/ld: cannot find -lunwind > >> > > /bin/ld: cannot find -lunwind-x86_64 > >> > > collect2: error: ld returned 1 exit status > >> > > make[1]: *** [perf] Error 1 > >> > > make[1]: *** Waiting for unfinished jobs.... > >> > > make: *** [all] Error 2 > >> > >> > > I haven't checked this one.. will do tomorrow > >> > >> > we need to plug libunwind flags/libs only if > >> > the $(feature-libunwind) is enabled.. > >> > >> > NO_LIBUNWIND - user's decision not to link with libunwind or > >> > architecture that does not support it > >> > >> > $(feature-libunwind) - if it's actually installed > >> > >> > attached change fixies that for me, feel free to use/merge it > >> > >> Argh, I used tests/make on one machine where those two patches by Jean > >> were not applied, then rebased on another, the one I use to submit, > >> those got included but not tests/make tested, which probably explains > >> why this got thru :-\ > >> > >> Jean, can you please check that this works for you on ARM too? > > > > I just noticed that this patch breaks the feature detection mechanism, > > after it is applied it is back performing all tests at every make call, > > this needs rethinking, so I'm dropping both. > Oh I am sorry about that. I tested on ARM with and without the > LIBUNWIND_DIR option set. > Let me rethink/rework this and come back to you with a proper fix. > > > > > Ingo, please disregard, yet again, my latest pull request, sigh. > > > > Jiri, this could be something for tests/make, till then I'll try > > to check this manually. > > One question though: are you OK with the principle of having > per-feature check flags? This brings two things to the feature > detection and build: > 1. the ability to specify specific flags for the feature check, which > is not possible on the current code, > 2. a simplification in the Makefiles.
looks good to me jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
