Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Mon, Dec 04, 2017 at 12:35:14PM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Dec 04, 2017 at 09:24:37AM +0100, Jiri Olsa escreveu: > > On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote: > > > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote: > > > > Hi Jiri, > > > > > > > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > > > > > From: Jiri Olsa> > > > > > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > > > hardened specs from redhat-rpm-config package. We apply them only > > > > > for perl/python objects, which makes them not compatible with the > > > > > rest of the objects and the build fails with: > > > > > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against > > > > > `.rodata.str1.1' can not be used when making a shared object; > > > > > recompile with -fPIC > > > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S > > > > > against `.text' can not be used when making a shared object; > > > > > recompile with -fPIC > > > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > > > collect2: error: ld returned 1 exit status > > > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > > > make: *** [Makefile:69: all] Error 2 > > > > > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > > > > > which prevent the final link impossible, because it will check > > > > > for 'proper' objects with following option: > > > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > > > > Just for curiousity, could you please show me the contents of the two > > > > files? (Are they big?) > > > > > > # cat /usr/lib/rpm/redhat/redhat-hardened-ld > > > *self_spec: > > > + %{!static:%{!shared:%{!r:-pie}}} > > > > > > *link: > > > + -z now > > > > > > > > > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 > > > *cc1_options: > > > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}} > > > > > > looks like we could remove that spec totaly and get things working > > we already do that for CC_NO_CLANG > > > > could you guys test patch below? works on my setup > > Works for me as well, builds in f27 with gcc and with clang, I've added > it to my perf/core branch with the original commig message modulo the > description of the original fix. > > If you want to have a different message, feel free to send it to me and > I'll make the adjustments if this takes place before my next pull req to > Ingo :-) saw it, looks good, thanks jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Mon, Dec 04, 2017 at 12:35:14PM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Dec 04, 2017 at 09:24:37AM +0100, Jiri Olsa escreveu: > > On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote: > > > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote: > > > > Hi Jiri, > > > > > > > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > > > > > From: Jiri Olsa > > > > > > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > > > hardened specs from redhat-rpm-config package. We apply them only > > > > > for perl/python objects, which makes them not compatible with the > > > > > rest of the objects and the build fails with: > > > > > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against > > > > > `.rodata.str1.1' can not be used when making a shared object; > > > > > recompile with -fPIC > > > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S > > > > > against `.text' can not be used when making a shared object; > > > > > recompile with -fPIC > > > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > > > collect2: error: ld returned 1 exit status > > > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > > > make: *** [Makefile:69: all] Error 2 > > > > > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > > > > > which prevent the final link impossible, because it will check > > > > > for 'proper' objects with following option: > > > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > > > > Just for curiousity, could you please show me the contents of the two > > > > files? (Are they big?) > > > > > > # cat /usr/lib/rpm/redhat/redhat-hardened-ld > > > *self_spec: > > > + %{!static:%{!shared:%{!r:-pie}}} > > > > > > *link: > > > + -z now > > > > > > > > > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 > > > *cc1_options: > > > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}} > > > > > > looks like we could remove that spec totaly and get things working > > we already do that for CC_NO_CLANG > > > > could you guys test patch below? works on my setup > > Works for me as well, builds in f27 with gcc and with clang, I've added > it to my perf/core branch with the original commig message modulo the > description of the original fix. > > If you want to have a different message, feel free to send it to me and > I'll make the adjustments if this takes place before my next pull req to > Ingo :-) saw it, looks good, thanks jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Mon, Dec 04, 2017 at 09:24:37AM +0100, Jiri Olsa escreveu: > On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote: > > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote: > > > Hi Jiri, > > > > > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > > > > From: Jiri Olsa> > > > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > > hardened specs from redhat-rpm-config package. We apply them only > > > > for perl/python objects, which makes them not compatible with the > > > > rest of the objects and the build fails with: > > > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against > > > > `.rodata.str1.1' can not be used when making a shared object; recompile > > > > with -fPIC > > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > > > `.text' can not be used when making a shared object; recompile with > > > > -fPIC > > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > > collect2: error: ld returned 1 exit status > > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > > make: *** [Makefile:69: all] Error 2 > > > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > > > which prevent the final link impossible, because it will check > > > > for 'proper' objects with following option: > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > > Just for curiousity, could you please show me the contents of the two > > > files? (Are they big?) > > > > # cat /usr/lib/rpm/redhat/redhat-hardened-ld > > *self_spec: > > + %{!static:%{!shared:%{!r:-pie}}} > > > > *link: > > + -z now > > > > > > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 > > *cc1_options: > > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}} > > > looks like we could remove that spec totaly and get things working > we already do that for CC_NO_CLANG > > could you guys test patch below? works on my setup Works for me as well, builds in f27 with gcc and with clang, I've added it to my perf/core branch with the original commig message modulo the description of the original fix. If you want to have a different message, feel free to send it to me and I'll make the adjustments if this takes place before my next pull req to Ingo :-) Thanks, - Arnaldo
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Mon, Dec 04, 2017 at 09:24:37AM +0100, Jiri Olsa escreveu: > On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote: > > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote: > > > Hi Jiri, > > > > > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > > > > From: Jiri Olsa > > > > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > > hardened specs from redhat-rpm-config package. We apply them only > > > > for perl/python objects, which makes them not compatible with the > > > > rest of the objects and the build fails with: > > > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against > > > > `.rodata.str1.1' can not be used when making a shared object; recompile > > > > with -fPIC > > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > > > `.text' can not be used when making a shared object; recompile with > > > > -fPIC > > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > > collect2: error: ld returned 1 exit status > > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > > make: *** [Makefile:69: all] Error 2 > > > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > > > which prevent the final link impossible, because it will check > > > > for 'proper' objects with following option: > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > > Just for curiousity, could you please show me the contents of the two > > > files? (Are they big?) > > > > # cat /usr/lib/rpm/redhat/redhat-hardened-ld > > *self_spec: > > + %{!static:%{!shared:%{!r:-pie}}} > > > > *link: > > + -z now > > > > > > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 > > *cc1_options: > > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}} > > > looks like we could remove that spec totaly and get things working > we already do that for CC_NO_CLANG > > could you guys test patch below? works on my setup Works for me as well, builds in f27 with gcc and with clang, I've added it to my perf/core branch with the original commig message modulo the description of the original fix. If you want to have a different message, feel free to send it to me and I'll make the adjustments if this takes place before my next pull req to Ingo :-) Thanks, - Arnaldo
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote: > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote: > > Hi Jiri, > > > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > > > From: Jiri Olsa> > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > hardened specs from redhat-rpm-config package. We apply them only > > > for perl/python objects, which makes them not compatible with the > > > rest of the objects and the build fails with: > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' > > > can not be used when making a shared object; recompile with -fPIC > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > > `.text' can not be used when making a shared object; recompile with -fPIC > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > collect2: error: ld returned 1 exit status > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > make: *** [Makefile:69: all] Error 2 > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > which prevent the final link impossible, because it will check > > > for 'proper' objects with following option: > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > Just for curiousity, could you please show me the contents of the two > > files? (Are they big?) > > # cat /usr/lib/rpm/redhat/redhat-hardened-ld > *self_spec: > + %{!static:%{!shared:%{!r:-pie}}} > > *link: > + -z now > > > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 > *cc1_options: > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}} looks like we could remove that spec totaly and get things working we already do that for CC_NO_CLANG could you guys test patch below? works on my setup thanks, jirka --- tools/perf/Makefile.config | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index c17472cb50f5..d702d21eacf6 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -184,9 +184,7 @@ ifdef PYTHON_CONFIG PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS)) PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null) - ifeq ($(CC_NO_CLANG), 1) -PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS)) - endif + PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS)) FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS) endif @@ -572,7 +570,6 @@ ifndef NO_GTK2 endif endif - ifdef NO_LIBPERL CFLAGS += -DNO_LIBPERL else @@ -580,6 +577,8 @@ else PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS)) PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS)) PERL_EMBED_CCOPTS = $(shell perl -MExtUtils::Embed -e ccopts 2>/dev/null) + PERL_EMBED_CCOPTS := $(filter-out -specs=%,$(PERL_EMBED_CCOPTS)) + PERL_EMBED_LDOPTS := $(filter-out -specs=%,$(PERL_EMBED_LDOPTS)) FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS) ifneq ($(feature-libperl), 1) -- 2.14.3
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote: > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote: > > Hi Jiri, > > > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > > > From: Jiri Olsa > > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > hardened specs from redhat-rpm-config package. We apply them only > > > for perl/python objects, which makes them not compatible with the > > > rest of the objects and the build fails with: > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' > > > can not be used when making a shared object; recompile with -fPIC > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > > `.text' can not be used when making a shared object; recompile with -fPIC > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > collect2: error: ld returned 1 exit status > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > make: *** [Makefile:69: all] Error 2 > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > which prevent the final link impossible, because it will check > > > for 'proper' objects with following option: > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > Just for curiousity, could you please show me the contents of the two > > files? (Are they big?) > > # cat /usr/lib/rpm/redhat/redhat-hardened-ld > *self_spec: > + %{!static:%{!shared:%{!r:-pie}}} > > *link: > + -z now > > > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 > *cc1_options: > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}} looks like we could remove that spec totaly and get things working we already do that for CC_NO_CLANG could you guys test patch below? works on my setup thanks, jirka --- tools/perf/Makefile.config | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index c17472cb50f5..d702d21eacf6 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -184,9 +184,7 @@ ifdef PYTHON_CONFIG PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS)) PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null) - ifeq ($(CC_NO_CLANG), 1) -PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS)) - endif + PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS)) FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS) endif @@ -572,7 +570,6 @@ ifndef NO_GTK2 endif endif - ifdef NO_LIBPERL CFLAGS += -DNO_LIBPERL else @@ -580,6 +577,8 @@ else PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS)) PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS)) PERL_EMBED_CCOPTS = $(shell perl -MExtUtils::Embed -e ccopts 2>/dev/null) + PERL_EMBED_CCOPTS := $(filter-out -specs=%,$(PERL_EMBED_CCOPTS)) + PERL_EMBED_LDOPTS := $(filter-out -specs=%,$(PERL_EMBED_LDOPTS)) FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS) ifneq ($(feature-libperl), 1) -- 2.14.3
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote: > Hi Jiri, > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > > From: Jiri Olsa> > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > hardened specs from redhat-rpm-config package. We apply them only > > for perl/python objects, which makes them not compatible with the > > rest of the objects and the build fails with: > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' > > can not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > `.text' can not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > collect2: error: ld returned 1 exit status > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > make: *** [Makefile:69: all] Error 2 > > > > Mainly it's caused by perl/python objects being compiled with: > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > which prevent the final link impossible, because it will check > > for 'proper' objects with following option: > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > Just for curiousity, could you please show me the contents of the two > files? (Are they big?) # cat /usr/lib/rpm/redhat/redhat-hardened-ld *self_spec: + %{!static:%{!shared:%{!r:-pie}}} *link: + -z now # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 *cc1_options: + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}} jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote: > Hi Jiri, > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > > From: Jiri Olsa > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > hardened specs from redhat-rpm-config package. We apply them only > > for perl/python objects, which makes them not compatible with the > > rest of the objects and the build fails with: > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' > > can not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > `.text' can not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > collect2: error: ld returned 1 exit status > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > make: *** [Makefile:69: all] Error 2 > > > > Mainly it's caused by perl/python objects being compiled with: > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > which prevent the final link impossible, because it will check > > for 'proper' objects with following option: > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > Just for curiousity, could you please show me the contents of the two > files? (Are they big?) # cat /usr/lib/rpm/redhat/redhat-hardened-ld *self_spec: + %{!static:%{!shared:%{!r:-pie}}} *link: + -z now # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 *cc1_options: + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}} jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Hi Jiri, On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > From: Jiri Olsa> > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > hardened specs from redhat-rpm-config package. We apply them only > for perl/python objects, which makes them not compatible with the > rest of the objects and the build fails with: > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can > not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > `.text' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile.perf:507: perf] Error 1 > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > make: *** [Makefile:69: all] Error 2 > > Mainly it's caused by perl/python objects being compiled with: > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > which prevent the final link impossible, because it will check > for 'proper' objects with following option: > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld Just for curiousity, could you please show me the contents of the two files? (Are they big?) Thanks, Namhyung > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > for all the objects. > > Link: http://lkml.kernel.org/n/tip-bib4nb5dei0ubk83534ef...@git.kernel.org > Signed-off-by: Jiri Olsa > --- > tools/perf/Makefile.config | 2 ++ > tools/perf/scripts/perl/Perf-Trace-Util/Build | 2 +- > tools/perf/scripts/python/Perf-Trace-Util/Build | 2 +- > tools/perf/util/block-range.c | 2 +- > tools/perf/util/scripting-engines/Build | 4 ++-- > 5 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config > index f6786fa2419f..5e3734e4c1e4 100644 > --- a/tools/perf/Makefile.config > +++ b/tools/perf/Makefile.config > @@ -587,6 +587,7 @@ else > NO_LIBPERL := 1 > msg := $(warning Missing perl devel files. Disabling perl scripting > support, please install perl-ExtUtils-Embed/libperl-dev); >else > +CFLAGS += $(PERL_EMBED_CCOPTS) > LDFLAGS += $(PERL_EMBED_LDFLAGS) > EXTLIBS += $(PERL_EMBED_LIBADD) > $(call detected,CONFIG_LIBPERL) > @@ -636,6 +637,7 @@ else >$(warning $(and ,)) >$(error $(and ,)) > else > + CFLAGS += $(PYTHON_EMBED_CCOPTS) >LDFLAGS += $(PYTHON_EMBED_LDFLAGS) >EXTLIBS += $(PYTHON_EMBED_LIBADD) >LANG_BINDINGS += $(obj-perf)python/perf.so > diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Build > b/tools/perf/scripts/perl/Perf-Trace-Util/Build > index 34faecf774ae..ff9a452677fc 100644 > --- a/tools/perf/scripts/perl/Perf-Trace-Util/Build > +++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build > @@ -1,5 +1,5 @@ > libperf-y += Context.o > > -CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls > -Wno-strict-prototypes > +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes > CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef > CFLAGS_Context.o += -Wno-switch-default -Wno-shadow > diff --git a/tools/perf/scripts/python/Perf-Trace-Util/Build > b/tools/perf/scripts/python/Perf-Trace-Util/Build > index aefc15c9444a..cd4da129c017 100644 > --- a/tools/perf/scripts/python/Perf-Trace-Util/Build > +++ b/tools/perf/scripts/python/Perf-Trace-Util/Build > @@ -1,3 +1,3 @@ > libperf-y += Context.o > > -CFLAGS_Context.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls > -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs > +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes > -Wno-unused-parameter -Wno-nested-externs > diff --git a/tools/perf/util/block-range.c b/tools/perf/util/block-range.c > index f1451c987eec..ff76d5f1d96f 100644 > --- a/tools/perf/util/block-range.c > +++ b/tools/perf/util/block-range.c > @@ -15,7 +15,7 @@ static void block_range__debug(void) >*/ > #if 1 > struct rb_node *rb; > - u64 old = 0; /* NULL isn't executable */ > + u64 old __maybe_unused = 0; /* NULL isn't executable */ > > for (rb = rb_first(_ranges.root); rb; rb = rb_next(rb)) { > struct block_range *entry = rb_entry(rb, struct block_range, > node); > diff --git a/tools/perf/util/scripting-engines/Build > b/tools/perf/util/scripting-engines/Build > index 82d28c67e0f3..38cd25ce1503 100644 > --- a/tools/perf/util/scripting-engines/Build > +++ b/tools/perf/util/scripting-engines/Build > @@ -1,6 +1,6 @@ > libperf-$(CONFIG_LIBPERL) += trace-event-perl.o > libperf-$(CONFIG_LIBPYTHON) += trace-event-python.o > > -CFLAGS_trace-event-perl.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls > -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs >
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Hi Jiri, On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote: > From: Jiri Olsa > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > hardened specs from redhat-rpm-config package. We apply them only > for perl/python objects, which makes them not compatible with the > rest of the objects and the build fails with: > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can > not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > `.text' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile.perf:507: perf] Error 1 > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > make: *** [Makefile:69: all] Error 2 > > Mainly it's caused by perl/python objects being compiled with: > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > which prevent the final link impossible, because it will check > for 'proper' objects with following option: > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld Just for curiousity, could you please show me the contents of the two files? (Are they big?) Thanks, Namhyung > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > for all the objects. > > Link: http://lkml.kernel.org/n/tip-bib4nb5dei0ubk83534ef...@git.kernel.org > Signed-off-by: Jiri Olsa > --- > tools/perf/Makefile.config | 2 ++ > tools/perf/scripts/perl/Perf-Trace-Util/Build | 2 +- > tools/perf/scripts/python/Perf-Trace-Util/Build | 2 +- > tools/perf/util/block-range.c | 2 +- > tools/perf/util/scripting-engines/Build | 4 ++-- > 5 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config > index f6786fa2419f..5e3734e4c1e4 100644 > --- a/tools/perf/Makefile.config > +++ b/tools/perf/Makefile.config > @@ -587,6 +587,7 @@ else > NO_LIBPERL := 1 > msg := $(warning Missing perl devel files. Disabling perl scripting > support, please install perl-ExtUtils-Embed/libperl-dev); >else > +CFLAGS += $(PERL_EMBED_CCOPTS) > LDFLAGS += $(PERL_EMBED_LDFLAGS) > EXTLIBS += $(PERL_EMBED_LIBADD) > $(call detected,CONFIG_LIBPERL) > @@ -636,6 +637,7 @@ else >$(warning $(and ,)) >$(error $(and ,)) > else > + CFLAGS += $(PYTHON_EMBED_CCOPTS) >LDFLAGS += $(PYTHON_EMBED_LDFLAGS) >EXTLIBS += $(PYTHON_EMBED_LIBADD) >LANG_BINDINGS += $(obj-perf)python/perf.so > diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Build > b/tools/perf/scripts/perl/Perf-Trace-Util/Build > index 34faecf774ae..ff9a452677fc 100644 > --- a/tools/perf/scripts/perl/Perf-Trace-Util/Build > +++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build > @@ -1,5 +1,5 @@ > libperf-y += Context.o > > -CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls > -Wno-strict-prototypes > +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes > CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef > CFLAGS_Context.o += -Wno-switch-default -Wno-shadow > diff --git a/tools/perf/scripts/python/Perf-Trace-Util/Build > b/tools/perf/scripts/python/Perf-Trace-Util/Build > index aefc15c9444a..cd4da129c017 100644 > --- a/tools/perf/scripts/python/Perf-Trace-Util/Build > +++ b/tools/perf/scripts/python/Perf-Trace-Util/Build > @@ -1,3 +1,3 @@ > libperf-y += Context.o > > -CFLAGS_Context.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls > -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs > +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes > -Wno-unused-parameter -Wno-nested-externs > diff --git a/tools/perf/util/block-range.c b/tools/perf/util/block-range.c > index f1451c987eec..ff76d5f1d96f 100644 > --- a/tools/perf/util/block-range.c > +++ b/tools/perf/util/block-range.c > @@ -15,7 +15,7 @@ static void block_range__debug(void) >*/ > #if 1 > struct rb_node *rb; > - u64 old = 0; /* NULL isn't executable */ > + u64 old __maybe_unused = 0; /* NULL isn't executable */ > > for (rb = rb_first(_ranges.root); rb; rb = rb_next(rb)) { > struct block_range *entry = rb_entry(rb, struct block_range, > node); > diff --git a/tools/perf/util/scripting-engines/Build > b/tools/perf/util/scripting-engines/Build > index 82d28c67e0f3..38cd25ce1503 100644 > --- a/tools/perf/util/scripting-engines/Build > +++ b/tools/perf/util/scripting-engines/Build > @@ -1,6 +1,6 @@ > libperf-$(CONFIG_LIBPERL) += trace-event-perl.o > libperf-$(CONFIG_LIBPYTHON) += trace-event-python.o > > -CFLAGS_trace-event-perl.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls > -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs > -Wno-undef -Wno-switch-default >
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Wed, Nov 29, 2017 at 05:00:19PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 29, 2017 at 04:54:46PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu: > > > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > > > > Right, since we want to honour what the distro makers decided was the > > > > best set for them, and to be able to link with other libraries, etc. > > > > > > But then I think this should be done more explicitely, right? Do you > > > > envision some way to do that without having to try to build perl or > > > > python, that may not be installed, etc? > > > > > I'll check on it.. I think we could use feature detection and > > > enable that by default and add NO_HARDENED_BUILD variable as > > > we do for features.. and detect that python/perl or whatever > > > else is using that and warn > > > > > > Of course users wanting to use something different may just set CFLAGS > > > > and be done with it, in which case I think this should also affect the > > > > perl and python CFLAGS, removing that distro specific stuff since the > > > > user is changing something different. > > > > > yep > > > > Even with this patch applied, as a stopgap solution to allow me to build > > a full featured tool on f27, I get this leftover: > > > > LINK /tmp/build/perf/perf > > /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation > > R_X86_64_32S against symbol `inat_primary_table' can not be used when > > making a shared object; recompile with -fPIC > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > collect2: error: ld returned 1 exit status > > > > > > Looking at the Intel PT bits now... > > Nevermind, I did a full rebuild and this is not there anymore, some > build artifact with that file :-\ I keep posponing this fix.. maybe I should update to F27 ;-) I'll send new version soon jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Wed, Nov 29, 2017 at 05:00:19PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 29, 2017 at 04:54:46PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu: > > > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > > > > Right, since we want to honour what the distro makers decided was the > > > > best set for them, and to be able to link with other libraries, etc. > > > > > > But then I think this should be done more explicitely, right? Do you > > > > envision some way to do that without having to try to build perl or > > > > python, that may not be installed, etc? > > > > > I'll check on it.. I think we could use feature detection and > > > enable that by default and add NO_HARDENED_BUILD variable as > > > we do for features.. and detect that python/perl or whatever > > > else is using that and warn > > > > > > Of course users wanting to use something different may just set CFLAGS > > > > and be done with it, in which case I think this should also affect the > > > > perl and python CFLAGS, removing that distro specific stuff since the > > > > user is changing something different. > > > > > yep > > > > Even with this patch applied, as a stopgap solution to allow me to build > > a full featured tool on f27, I get this leftover: > > > > LINK /tmp/build/perf/perf > > /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation > > R_X86_64_32S against symbol `inat_primary_table' can not be used when > > making a shared object; recompile with -fPIC > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > collect2: error: ld returned 1 exit status > > > > > > Looking at the Intel PT bits now... > > Nevermind, I did a full rebuild and this is not there anymore, some > build artifact with that file :-\ I keep posponing this fix.. maybe I should update to F27 ;-) I'll send new version soon jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Wed, Nov 29, 2017 at 04:54:46PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu: > > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > > > Right, since we want to honour what the distro makers decided was the > > > best set for them, and to be able to link with other libraries, etc. > > > > But then I think this should be done more explicitely, right? Do you > > > envision some way to do that without having to try to build perl or > > > python, that may not be installed, etc? > > > I'll check on it.. I think we could use feature detection and > > enable that by default and add NO_HARDENED_BUILD variable as > > we do for features.. and detect that python/perl or whatever > > else is using that and warn > > > > Of course users wanting to use something different may just set CFLAGS > > > and be done with it, in which case I think this should also affect the > > > perl and python CFLAGS, removing that distro specific stuff since the > > > user is changing something different. > > > yep > > Even with this patch applied, as a stopgap solution to allow me to build > a full featured tool on f27, I get this leftover: > > LINK /tmp/build/perf/perf > /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S > against symbol `inat_primary_table' can not be used when making a shared > object; recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > > > Looking at the Intel PT bits now... Nevermind, I did a full rebuild and this is not there anymore, some build artifact with that file :-\ - Arnaldo
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Wed, Nov 29, 2017 at 04:54:46PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu: > > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > > > Right, since we want to honour what the distro makers decided was the > > > best set for them, and to be able to link with other libraries, etc. > > > > But then I think this should be done more explicitely, right? Do you > > > envision some way to do that without having to try to build perl or > > > python, that may not be installed, etc? > > > I'll check on it.. I think we could use feature detection and > > enable that by default and add NO_HARDENED_BUILD variable as > > we do for features.. and detect that python/perl or whatever > > else is using that and warn > > > > Of course users wanting to use something different may just set CFLAGS > > > and be done with it, in which case I think this should also affect the > > > perl and python CFLAGS, removing that distro specific stuff since the > > > user is changing something different. > > > yep > > Even with this patch applied, as a stopgap solution to allow me to build > a full featured tool on f27, I get this leftover: > > LINK /tmp/build/perf/perf > /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S > against symbol `inat_primary_table' can not be used when making a shared > object; recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > > > Looking at the Intel PT bits now... Nevermind, I did a full rebuild and this is not there anymore, some build artifact with that file :-\ - Arnaldo
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu: > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > > Right, since we want to honour what the distro makers decided was the > > best set for them, and to be able to link with other libraries, etc. > > But then I think this should be done more explicitely, right? Do you > > envision some way to do that without having to try to build perl or > > python, that may not be installed, etc? > I'll check on it.. I think we could use feature detection and > enable that by default and add NO_HARDENED_BUILD variable as > we do for features.. and detect that python/perl or whatever > else is using that and warn > > Of course users wanting to use something different may just set CFLAGS > > and be done with it, in which case I think this should also affect the > > perl and python CFLAGS, removing that distro specific stuff since the > > user is changing something different. > yep Even with this patch applied, as a stopgap solution to allow me to build a full featured tool on f27, I get this leftover: LINK /tmp/build/perf/perf /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S against symbol `inat_primary_table' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status Looking at the Intel PT bits now... - Arnaldo
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu: > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > > Right, since we want to honour what the distro makers decided was the > > best set for them, and to be able to link with other libraries, etc. > > But then I think this should be done more explicitely, right? Do you > > envision some way to do that without having to try to build perl or > > python, that may not be installed, etc? > I'll check on it.. I think we could use feature detection and > enable that by default and add NO_HARDENED_BUILD variable as > we do for features.. and detect that python/perl or whatever > else is using that and warn > > Of course users wanting to use something different may just set CFLAGS > > and be done with it, in which case I think this should also affect the > > perl and python CFLAGS, removing that distro specific stuff since the > > user is changing something different. > yep Even with this patch applied, as a stopgap solution to allow me to build a full featured tool on f27, I get this leftover: LINK /tmp/build/perf/perf /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S against symbol `inat_primary_table' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status Looking at the Intel PT bits now... - Arnaldo
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Thu, Nov 23, 2017 at 11:15:32AM -0300, Arnaldo Carvalho de Melo wrote: SNIP > > I stumbled it on a recently created perf build container for fedora 27: > > fedora:27 > Downloading http://192.168.124.1/perf/perf-4.14.0.tar.xz... > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft Speed > > make: Entering directory '/git/linux/tools/perf' > BUILD: Doing 'make -j4 parallel build > HOSTCC /tmp/build/perf/fixdep.o > HOSTLD /tmp/build/perf/fixdep-in.o > LINK /tmp/build/perf/fixdep > > Auto-detecting system features: > ... dwarf: [ on ] > ...dwarf_getlocations: [ on ] > ... glibc: [ on ] > ... gtk2: [ on ] > ... libaudit: [ on ] > ...libbfd: [ on ] > ...libelf: [ on ] > ... libnuma: [ on ] > ...numa_num_possible_cpus: [ on ] > ... libperl: [ on ] > ... libpython: [ on ] > ... libslang: [ on ] > ... libcrypto: [ on ] > ... libunwind: [ on ] > ...libdw-dwarf-unwind: [ on ] > ... zlib: [ on ] > ... lzma: [ on ] > ... get_cpuid: [ on ] > ... bpf: [ on ] > > Makefile.config:813: No openjdk development package found, please install JDK > package > GEN /tmp/build/perf/common-cmds.h > PERF_VERSION = 4.14.geae86e > MKDIR/tmp/build/perf/fd/ > CC /tmp/build/perf/fd/array.o > CC /tmp/build/perf/exec-cmd.o > CC /tmp/build/perf/util/parse-events-flex.o > > LD /tmp/build/perf/util/libperf-in.o > LD /tmp/build/perf/libperf-in.o > AR /tmp/build/perf/libperf.a > LINK /tmp/build/perf/perf > LINK /tmp/build/perf/libperf-gtk.so > /usr/bin/ld: /tmp/build/perf/perf-in.o: relocation R_X86_64_32 against > `.rodata.str1.1' can not be used when making a shared object; recompile with > -fPIC > /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S > against `.text' can not be used when making a shared object; recompile with > -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile.perf:507: /tmp/build/perf/perf] Error 1 > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > make: *** [Makefile:70: all] Error 2 > make: Leaving directory '/git/linux/tools/perf' yep, thats the one ;-) I'll try to repost shortly jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Thu, Nov 23, 2017 at 11:15:32AM -0300, Arnaldo Carvalho de Melo wrote: SNIP > > I stumbled it on a recently created perf build container for fedora 27: > > fedora:27 > Downloading http://192.168.124.1/perf/perf-4.14.0.tar.xz... > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft Speed > > make: Entering directory '/git/linux/tools/perf' > BUILD: Doing 'make -j4 parallel build > HOSTCC /tmp/build/perf/fixdep.o > HOSTLD /tmp/build/perf/fixdep-in.o > LINK /tmp/build/perf/fixdep > > Auto-detecting system features: > ... dwarf: [ on ] > ...dwarf_getlocations: [ on ] > ... glibc: [ on ] > ... gtk2: [ on ] > ... libaudit: [ on ] > ...libbfd: [ on ] > ...libelf: [ on ] > ... libnuma: [ on ] > ...numa_num_possible_cpus: [ on ] > ... libperl: [ on ] > ... libpython: [ on ] > ... libslang: [ on ] > ... libcrypto: [ on ] > ... libunwind: [ on ] > ...libdw-dwarf-unwind: [ on ] > ... zlib: [ on ] > ... lzma: [ on ] > ... get_cpuid: [ on ] > ... bpf: [ on ] > > Makefile.config:813: No openjdk development package found, please install JDK > package > GEN /tmp/build/perf/common-cmds.h > PERF_VERSION = 4.14.geae86e > MKDIR/tmp/build/perf/fd/ > CC /tmp/build/perf/fd/array.o > CC /tmp/build/perf/exec-cmd.o > CC /tmp/build/perf/util/parse-events-flex.o > > LD /tmp/build/perf/util/libperf-in.o > LD /tmp/build/perf/libperf-in.o > AR /tmp/build/perf/libperf.a > LINK /tmp/build/perf/perf > LINK /tmp/build/perf/libperf-gtk.so > /usr/bin/ld: /tmp/build/perf/perf-in.o: relocation R_X86_64_32 against > `.rodata.str1.1' can not be used when making a shared object; recompile with > -fPIC > /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S > against `.text' can not be used when making a shared object; recompile with > -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile.perf:507: /tmp/build/perf/perf] Error 1 > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > make: *** [Makefile:70: all] Error 2 > make: Leaving directory '/git/linux/tools/perf' yep, thats the one ;-) I'll try to repost shortly jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu: > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu: > > > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > which prevent the final link impossible, because it will check > > > > > for 'proper' objects with following option: > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > > > > > for all the objects. > > > > Humm, so we're basically using the hardened config only we build with > > > > PERL or PYTHON, should we use that always, i.e. ask the distro what set > > > > of flags we should use? > > > right, I think this needs to be detected like we do for features, > > > since there maybe some supported gcc versions to detect > > Right, since we want to honour what the distro makers decided was the > > best set for them, and to be able to link with other libraries, etc. > > But then I think this should be done more explicitely, right? Do you > > envision some way to do that without having to try to build perl or > > python, that may not be installed, etc? > I'll check on it.. I think we could use feature detection and > enable that by default and add NO_HARDENED_BUILD variable as > we do for features.. and detect that python/perl or whatever > else is using that and warn I stumbled it on a recently created perf build container for fedora 27: fedora:27 Downloading http://192.168.124.1/perf/perf-4.14.0.tar.xz... % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed make: Entering directory '/git/linux/tools/perf' BUILD: Doing 'make -j4 parallel build HOSTCC /tmp/build/perf/fixdep.o HOSTLD /tmp/build/perf/fixdep-in.o LINK /tmp/build/perf/fixdep Auto-detecting system features: ... dwarf: [ on ] ...dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libnuma: [ on ] ...numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ...libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] Makefile.config:813: No openjdk development package found, please install JDK package GEN /tmp/build/perf/common-cmds.h PERF_VERSION = 4.14.geae86e MKDIR/tmp/build/perf/fd/ CC /tmp/build/perf/fd/array.o CC /tmp/build/perf/exec-cmd.o CC /tmp/build/perf/util/parse-events-flex.o LD /tmp/build/perf/util/libperf-in.o LD /tmp/build/perf/libperf-in.o AR /tmp/build/perf/libperf.a LINK /tmp/build/perf/perf LINK /tmp/build/perf/libperf-gtk.so /usr/bin/ld: /tmp/build/perf/perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status make[2]: *** [Makefile.perf:507: /tmp/build/perf/perf] Error 1 make[1]: *** [Makefile.perf:210: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 make: Leaving directory '/git/linux/tools/perf'
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu: > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu: > > > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > which prevent the final link impossible, because it will check > > > > > for 'proper' objects with following option: > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > > > > > for all the objects. > > > > Humm, so we're basically using the hardened config only we build with > > > > PERL or PYTHON, should we use that always, i.e. ask the distro what set > > > > of flags we should use? > > > right, I think this needs to be detected like we do for features, > > > since there maybe some supported gcc versions to detect > > Right, since we want to honour what the distro makers decided was the > > best set for them, and to be able to link with other libraries, etc. > > But then I think this should be done more explicitely, right? Do you > > envision some way to do that without having to try to build perl or > > python, that may not be installed, etc? > I'll check on it.. I think we could use feature detection and > enable that by default and add NO_HARDENED_BUILD variable as > we do for features.. and detect that python/perl or whatever > else is using that and warn I stumbled it on a recently created perf build container for fedora 27: fedora:27 Downloading http://192.168.124.1/perf/perf-4.14.0.tar.xz... % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed make: Entering directory '/git/linux/tools/perf' BUILD: Doing 'make -j4 parallel build HOSTCC /tmp/build/perf/fixdep.o HOSTLD /tmp/build/perf/fixdep-in.o LINK /tmp/build/perf/fixdep Auto-detecting system features: ... dwarf: [ on ] ...dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libnuma: [ on ] ...numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ...libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] Makefile.config:813: No openjdk development package found, please install JDK package GEN /tmp/build/perf/common-cmds.h PERF_VERSION = 4.14.geae86e MKDIR/tmp/build/perf/fd/ CC /tmp/build/perf/fd/array.o CC /tmp/build/perf/exec-cmd.o CC /tmp/build/perf/util/parse-events-flex.o LD /tmp/build/perf/util/libperf-in.o LD /tmp/build/perf/libperf-in.o AR /tmp/build/perf/libperf.a LINK /tmp/build/perf/perf LINK /tmp/build/perf/libperf-gtk.so /usr/bin/ld: /tmp/build/perf/perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status make[2]: *** [Makefile.perf:507: /tmp/build/perf/perf] Error 1 make[1]: *** [Makefile.perf:210: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 make: Leaving directory '/git/linux/tools/perf'
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu: > > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > > > > From: Jiri Olsa> > > > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > > hardened specs from redhat-rpm-config package. We apply them only > > > > for perl/python objects, which makes them not compatible with the > > > > rest of the objects and the build fails with: > > > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against > > > > `.rodata.str1.1' can not be used when making a shared object; recompile > > > > with -fPIC > > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > > > `.text' can not be used when making a shared object; recompile with > > > > -fPIC > > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > > collect2: error: ld returned 1 exit status > > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > > make: *** [Makefile:69: all] Error 2 > > > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > > > which prevent the final link impossible, because it will check > > > > for 'proper' objects with following option: > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > > > > for all the objects. > > > > > > Humm, so we're basically using the hardened config only we build with > > > PERL or PYTHON, should we use that always, i.e. ask the distro what set > > > of flags we should use? > > > > right, I think this needs to be detected like we do for features, > > since there maybe some supported gcc versions to detect > > Right, since we want to honour what the distro makers decided was the > best set for them, and to be able to link with other libraries, etc. > > But then I think this should be done more explicitely, right? Do you > envision some way to do that without having to try to build perl or > python, that may not be installed, etc? > I'll check on it.. I think we could use feature detection and enable that by default and add NO_HARDENED_BUILD variable as we do for features.. and detect that python/perl or whatever else is using that and warn > Of course users wanting to use something different may just set CFLAGS > and be done with it, in which case I think this should also affect the > perl and python CFLAGS, removing that distro specific stuff since the > user is changing something different. yep jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu: > > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > > > > From: Jiri Olsa > > > > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > > hardened specs from redhat-rpm-config package. We apply them only > > > > for perl/python objects, which makes them not compatible with the > > > > rest of the objects and the build fails with: > > > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against > > > > `.rodata.str1.1' can not be used when making a shared object; recompile > > > > with -fPIC > > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > > > `.text' can not be used when making a shared object; recompile with > > > > -fPIC > > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > > collect2: error: ld returned 1 exit status > > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > > make: *** [Makefile:69: all] Error 2 > > > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > > > which prevent the final link impossible, because it will check > > > > for 'proper' objects with following option: > > > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > > > > for all the objects. > > > > > > Humm, so we're basically using the hardened config only we build with > > > PERL or PYTHON, should we use that always, i.e. ask the distro what set > > > of flags we should use? > > > > right, I think this needs to be detected like we do for features, > > since there maybe some supported gcc versions to detect > > Right, since we want to honour what the distro makers decided was the > best set for them, and to be able to link with other libraries, etc. > > But then I think this should be done more explicitely, right? Do you > envision some way to do that without having to try to build perl or > python, that may not be installed, etc? > I'll check on it.. I think we could use feature detection and enable that by default and add NO_HARDENED_BUILD variable as we do for features.. and detect that python/perl or whatever else is using that and warn > Of course users wanting to use something different may just set CFLAGS > and be done with it, in which case I think this should also affect the > perl and python CFLAGS, removing that distro specific stuff since the > user is changing something different. yep jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu: > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > > > From: Jiri Olsa> > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > hardened specs from redhat-rpm-config package. We apply them only > > > for perl/python objects, which makes them not compatible with the > > > rest of the objects and the build fails with: > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' > > > can not be used when making a shared object; recompile with -fPIC > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > > `.text' can not be used when making a shared object; recompile with -fPIC > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > collect2: error: ld returned 1 exit status > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > make: *** [Makefile:69: all] Error 2 > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > which prevent the final link impossible, because it will check > > > for 'proper' objects with following option: > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > > > for all the objects. > > > > Humm, so we're basically using the hardened config only we build with > > PERL or PYTHON, should we use that always, i.e. ask the distro what set > > of flags we should use? > > right, I think this needs to be detected like we do for features, > since there maybe some supported gcc versions to detect Right, since we want to honour what the distro makers decided was the best set for them, and to be able to link with other libraries, etc. But then I think this should be done more explicitely, right? Do you envision some way to do that without having to try to build perl or python, that may not be installed, etc? Of course users wanting to use something different may just set CFLAGS and be done with it, in which case I think this should also affect the perl and python CFLAGS, removing that distro specific stuff since the user is changing something different. > > What other impacts this may have on using this for all of the tools? > > I.e. we could conceivably just remove that part from the perl/python > > builds and make them use what has been used for the rest of the tools > > instead? > > hum, so those are the flags the perl/python extensions are built with > > we have both perl/python extensions built in the perf for the script cmd, > which creates dependencies: > > [jolsa@krava perf]$ ldd ./perf |grep perl > libperl.so.5.24 => /lib64/libperl.so.5.24 (0x7f72b33b3000) > [jolsa@krava perf]$ ldd ./perf |grep python > libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 > (0x7f927cfe7000) > > not sure we could be affected here if we remove that hardened spec > option > > and then we have the python module extension which is used separately of > perf binary, which should be fine > > jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu: > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > > > From: Jiri Olsa > > > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > > hardened specs from redhat-rpm-config package. We apply them only > > > for perl/python objects, which makes them not compatible with the > > > rest of the objects and the build fails with: > > > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' > > > can not be used when making a shared object; recompile with -fPIC > > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > > `.text' can not be used when making a shared object; recompile with -fPIC > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > collect2: error: ld returned 1 exit status > > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > > make: *** [Makefile:69: all] Error 2 > > > > > > Mainly it's caused by perl/python objects being compiled with: > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > > > which prevent the final link impossible, because it will check > > > for 'proper' objects with following option: > > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > > > for all the objects. > > > > Humm, so we're basically using the hardened config only we build with > > PERL or PYTHON, should we use that always, i.e. ask the distro what set > > of flags we should use? > > right, I think this needs to be detected like we do for features, > since there maybe some supported gcc versions to detect Right, since we want to honour what the distro makers decided was the best set for them, and to be able to link with other libraries, etc. But then I think this should be done more explicitely, right? Do you envision some way to do that without having to try to build perl or python, that may not be installed, etc? Of course users wanting to use something different may just set CFLAGS and be done with it, in which case I think this should also affect the perl and python CFLAGS, removing that distro specific stuff since the user is changing something different. > > What other impacts this may have on using this for all of the tools? > > I.e. we could conceivably just remove that part from the perl/python > > builds and make them use what has been used for the rest of the tools > > instead? > > hum, so those are the flags the perl/python extensions are built with > > we have both perl/python extensions built in the perf for the script cmd, > which creates dependencies: > > [jolsa@krava perf]$ ldd ./perf |grep perl > libperl.so.5.24 => /lib64/libperl.so.5.24 (0x7f72b33b3000) > [jolsa@krava perf]$ ldd ./perf |grep python > libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 > (0x7f927cfe7000) > > not sure we could be affected here if we remove that hardened spec > option > > and then we have the python module extension which is used separately of > perf binary, which should be fine > > jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > > From: Jiri Olsa> > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > hardened specs from redhat-rpm-config package. We apply them only > > for perl/python objects, which makes them not compatible with the > > rest of the objects and the build fails with: > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' > > can not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > `.text' can not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > collect2: error: ld returned 1 exit status > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > make: *** [Makefile:69: all] Error 2 > > > > Mainly it's caused by perl/python objects being compiled with: > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > which prevent the final link impossible, because it will check > > for 'proper' objects with following option: > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > > for all the objects. > > Humm, so we're basically using the hardened config only we build with > PERL or PYTHON, should we use that always, i.e. ask the distro what set > of flags we should use? right, I think this needs to be detected like we do for features, since there maybe some supported gcc versions to detect > What other impacts this may have on using this for all of the tools? > I.e. we could conceivably just remove that part from the perl/python > builds and make them use what has been used for the rest of the tools > instead? hum, so those are the flags the perl/python extensions are built with we have both perl/python extensions built in the perf for the script cmd, which creates dependencies: [jolsa@krava perf]$ ldd ./perf |grep perl libperl.so.5.24 => /lib64/libperl.so.5.24 (0x7f72b33b3000) [jolsa@krava perf]$ ldd ./perf |grep python libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x7f927cfe7000) not sure we could be affected here if we remove that hardened spec option and then we have the python module extension which is used separately of perf binary, which should be fine jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > > From: Jiri Olsa > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > > hardened specs from redhat-rpm-config package. We apply them only > > for perl/python objects, which makes them not compatible with the > > rest of the objects and the build fails with: > > > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' > > can not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > > `.text' can not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > collect2: error: ld returned 1 exit status > > make[2]: *** [Makefile.perf:507: perf] Error 1 > > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > > make: *** [Makefile:69: all] Error 2 > > > > Mainly it's caused by perl/python objects being compiled with: > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > > > which prevent the final link impossible, because it will check > > for 'proper' objects with following option: > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > > for all the objects. > > Humm, so we're basically using the hardened config only we build with > PERL or PYTHON, should we use that always, i.e. ask the distro what set > of flags we should use? right, I think this needs to be detected like we do for features, since there maybe some supported gcc versions to detect > What other impacts this may have on using this for all of the tools? > I.e. we could conceivably just remove that part from the perl/python > builds and make them use what has been used for the rest of the tools > instead? hum, so those are the flags the perl/python extensions are built with we have both perl/python extensions built in the perf for the script cmd, which creates dependencies: [jolsa@krava perf]$ ldd ./perf |grep perl libperl.so.5.24 => /lib64/libperl.so.5.24 (0x7f72b33b3000) [jolsa@krava perf]$ ldd ./perf |grep python libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x7f927cfe7000) not sure we could be affected here if we remove that hardened spec option and then we have the python module extension which is used separately of perf binary, which should be fine jirka
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > From: Jiri Olsa> > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > hardened specs from redhat-rpm-config package. We apply them only > for perl/python objects, which makes them not compatible with the > rest of the objects and the build fails with: > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can > not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > `.text' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile.perf:507: perf] Error 1 > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > make: *** [Makefile:69: all] Error 2 > > Mainly it's caused by perl/python objects being compiled with: > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > which prevent the final link impossible, because it will check > for 'proper' objects with following option: > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > for all the objects. Humm, so we're basically using the hardened config only we build with PERL or PYTHON, should we use that always, i.e. ask the distro what set of flags we should use? What other impacts this may have on using this for all of the tools? I.e. we could conceivably just remove that part from the perl/python builds and make them use what has been used for the rest of the tools instead? - Arnaldo
Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu: > From: Jiri Olsa > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the > hardened specs from redhat-rpm-config package. We apply them only > for perl/python objects, which makes them not compatible with the > rest of the objects and the build fails with: > > /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can > not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against > `.text' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile.perf:507: perf] Error 1 > make[1]: *** [Makefile.perf:210: sub-make] Error 2 > make: *** [Makefile:69: all] Error 2 > > Mainly it's caused by perl/python objects being compiled with: > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > which prevent the final link impossible, because it will check > for 'proper' objects with following option: > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > > Fixing this by using the perl/python CFLAGS/LDFLAGS options > for all the objects. Humm, so we're basically using the hardened config only we build with PERL or PYTHON, should we use that always, i.e. ask the distro what set of flags we should use? What other impacts this may have on using this for all of the tools? I.e. we could conceivably just remove that part from the perl/python builds and make them use what has been used for the rest of the tools instead? - Arnaldo
[PATCH 2/3] perf tools: Fix build for hardened environments
From: Jiri OlsaOn Fedora systems the perl and python CFLAGS/LDFLAGS include the hardened specs from redhat-rpm-config package. We apply them only for perl/python objects, which makes them not compatible with the rest of the objects and the build fails with: /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status make[2]: *** [Makefile.perf:507: perf] Error 1 make[1]: *** [Makefile.perf:210: sub-make] Error 2 make: *** [Makefile:69: all] Error 2 Mainly it's caused by perl/python objects being compiled with: -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 which prevent the final link impossible, because it will check for 'proper' objects with following option: -specs=/usr/lib/rpm/redhat/redhat-hardened-ld Fixing this by using the perl/python CFLAGS/LDFLAGS options for all the objects. Link: http://lkml.kernel.org/n/tip-bib4nb5dei0ubk83534ef...@git.kernel.org Signed-off-by: Jiri Olsa --- tools/perf/Makefile.config | 2 ++ tools/perf/scripts/perl/Perf-Trace-Util/Build | 2 +- tools/perf/scripts/python/Perf-Trace-Util/Build | 2 +- tools/perf/util/block-range.c | 2 +- tools/perf/util/scripting-engines/Build | 4 ++-- 5 files changed, 7 insertions(+), 5 deletions(-) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index f6786fa2419f..5e3734e4c1e4 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -587,6 +587,7 @@ else NO_LIBPERL := 1 msg := $(warning Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev); else +CFLAGS += $(PERL_EMBED_CCOPTS) LDFLAGS += $(PERL_EMBED_LDFLAGS) EXTLIBS += $(PERL_EMBED_LIBADD) $(call detected,CONFIG_LIBPERL) @@ -636,6 +637,7 @@ else $(warning $(and ,)) $(error $(and ,)) else + CFLAGS += $(PYTHON_EMBED_CCOPTS) LDFLAGS += $(PYTHON_EMBED_LDFLAGS) EXTLIBS += $(PYTHON_EMBED_LIBADD) LANG_BINDINGS += $(obj-perf)python/perf.so diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Build b/tools/perf/scripts/perl/Perf-Trace-Util/Build index 34faecf774ae..ff9a452677fc 100644 --- a/tools/perf/scripts/perl/Perf-Trace-Util/Build +++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build @@ -1,5 +1,5 @@ libperf-y += Context.o -CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef CFLAGS_Context.o += -Wno-switch-default -Wno-shadow diff --git a/tools/perf/scripts/python/Perf-Trace-Util/Build b/tools/perf/scripts/python/Perf-Trace-Util/Build index aefc15c9444a..cd4da129c017 100644 --- a/tools/perf/scripts/python/Perf-Trace-Util/Build +++ b/tools/perf/scripts/python/Perf-Trace-Util/Build @@ -1,3 +1,3 @@ libperf-y += Context.o -CFLAGS_Context.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs diff --git a/tools/perf/util/block-range.c b/tools/perf/util/block-range.c index f1451c987eec..ff76d5f1d96f 100644 --- a/tools/perf/util/block-range.c +++ b/tools/perf/util/block-range.c @@ -15,7 +15,7 @@ static void block_range__debug(void) */ #if 1 struct rb_node *rb; - u64 old = 0; /* NULL isn't executable */ + u64 old __maybe_unused = 0; /* NULL isn't executable */ for (rb = rb_first(_ranges.root); rb; rb = rb_next(rb)) { struct block_range *entry = rb_entry(rb, struct block_range, node); diff --git a/tools/perf/util/scripting-engines/Build b/tools/perf/util/scripting-engines/Build index 82d28c67e0f3..38cd25ce1503 100644 --- a/tools/perf/util/scripting-engines/Build +++ b/tools/perf/util/scripting-engines/Build @@ -1,6 +1,6 @@ libperf-$(CONFIG_LIBPERL) += trace-event-perl.o libperf-$(CONFIG_LIBPYTHON) += trace-event-python.o -CFLAGS_trace-event-perl.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs -Wno-undef -Wno-switch-default +CFLAGS_trace-event-perl.o += -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs -Wno-undef -Wno-switch-default -CFLAGS_trace-event-python.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow +CFLAGS_trace-event-python.o += -Wno-redundant-decls
[PATCH 2/3] perf tools: Fix build for hardened environments
From: Jiri Olsa On Fedora systems the perl and python CFLAGS/LDFLAGS include the hardened specs from redhat-rpm-config package. We apply them only for perl/python objects, which makes them not compatible with the rest of the objects and the build fails with: /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status make[2]: *** [Makefile.perf:507: perf] Error 1 make[1]: *** [Makefile.perf:210: sub-make] Error 2 make: *** [Makefile:69: all] Error 2 Mainly it's caused by perl/python objects being compiled with: -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 which prevent the final link impossible, because it will check for 'proper' objects with following option: -specs=/usr/lib/rpm/redhat/redhat-hardened-ld Fixing this by using the perl/python CFLAGS/LDFLAGS options for all the objects. Link: http://lkml.kernel.org/n/tip-bib4nb5dei0ubk83534ef...@git.kernel.org Signed-off-by: Jiri Olsa --- tools/perf/Makefile.config | 2 ++ tools/perf/scripts/perl/Perf-Trace-Util/Build | 2 +- tools/perf/scripts/python/Perf-Trace-Util/Build | 2 +- tools/perf/util/block-range.c | 2 +- tools/perf/util/scripting-engines/Build | 4 ++-- 5 files changed, 7 insertions(+), 5 deletions(-) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index f6786fa2419f..5e3734e4c1e4 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -587,6 +587,7 @@ else NO_LIBPERL := 1 msg := $(warning Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev); else +CFLAGS += $(PERL_EMBED_CCOPTS) LDFLAGS += $(PERL_EMBED_LDFLAGS) EXTLIBS += $(PERL_EMBED_LIBADD) $(call detected,CONFIG_LIBPERL) @@ -636,6 +637,7 @@ else $(warning $(and ,)) $(error $(and ,)) else + CFLAGS += $(PYTHON_EMBED_CCOPTS) LDFLAGS += $(PYTHON_EMBED_LDFLAGS) EXTLIBS += $(PYTHON_EMBED_LIBADD) LANG_BINDINGS += $(obj-perf)python/perf.so diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Build b/tools/perf/scripts/perl/Perf-Trace-Util/Build index 34faecf774ae..ff9a452677fc 100644 --- a/tools/perf/scripts/perl/Perf-Trace-Util/Build +++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build @@ -1,5 +1,5 @@ libperf-y += Context.o -CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef CFLAGS_Context.o += -Wno-switch-default -Wno-shadow diff --git a/tools/perf/scripts/python/Perf-Trace-Util/Build b/tools/perf/scripts/python/Perf-Trace-Util/Build index aefc15c9444a..cd4da129c017 100644 --- a/tools/perf/scripts/python/Perf-Trace-Util/Build +++ b/tools/perf/scripts/python/Perf-Trace-Util/Build @@ -1,3 +1,3 @@ libperf-y += Context.o -CFLAGS_Context.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs diff --git a/tools/perf/util/block-range.c b/tools/perf/util/block-range.c index f1451c987eec..ff76d5f1d96f 100644 --- a/tools/perf/util/block-range.c +++ b/tools/perf/util/block-range.c @@ -15,7 +15,7 @@ static void block_range__debug(void) */ #if 1 struct rb_node *rb; - u64 old = 0; /* NULL isn't executable */ + u64 old __maybe_unused = 0; /* NULL isn't executable */ for (rb = rb_first(_ranges.root); rb; rb = rb_next(rb)) { struct block_range *entry = rb_entry(rb, struct block_range, node); diff --git a/tools/perf/util/scripting-engines/Build b/tools/perf/util/scripting-engines/Build index 82d28c67e0f3..38cd25ce1503 100644 --- a/tools/perf/util/scripting-engines/Build +++ b/tools/perf/util/scripting-engines/Build @@ -1,6 +1,6 @@ libperf-$(CONFIG_LIBPERL) += trace-event-perl.o libperf-$(CONFIG_LIBPYTHON) += trace-event-python.o -CFLAGS_trace-event-perl.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs -Wno-undef -Wno-switch-default +CFLAGS_trace-event-perl.o += -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs -Wno-undef -Wno-switch-default -CFLAGS_trace-event-python.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow +CFLAGS_trace-event-python.o += -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter