perf tools: Build fixes

Using the shell function for perl cflags retrieval instead of back quotes (``). Both execute shell with the command, but the latter is more explicit and seems to be the preferred way.

Also we don't have any other use of the back quotes in perf Makefiles.

From: Jiri Olsa <[email protected]>

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.

Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:

Quoted 22 lines

From: Jiri Olsa <[email protected]>

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:

Quoted 4 lines

-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?

Quoted 28 lines

Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:

Quoted 26 lines

From: Jiri Olsa <[email protected]>

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.

Quoted 3 lines

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

Quoted 4 lines

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 (0x00007f72b33b3000)
[jolsa@krava perf]$ ldd ./perf |grep python
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f927cfe7000)

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

Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu:

Quoted 29 lines · Arnaldo Carvalho de Melo

Quoted 28 lines

Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:

Quoted 26 lines

From: Jiri Olsa <[email protected]>

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 24 lines

Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu:

Quoted 14 lines · Arnaldo Carvalho de Melo

Quoted 12 lines

Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:

Quoted 11 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 3 lines

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   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  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
<SNIP>
  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'

Quoted 6 lines

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

Quoted 4 lines

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

Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:

Quoted 13 lines · Arnaldo Carvalho de Melo

Quoted 6 lines

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

Quoted 6 lines

Quoted 4 lines

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...

Em Wed, Nov 29, 2017 at 04:54:46PM -0300, Arnaldo Carvalho de Melo escreveu:

Quoted 30 lines

Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:

Quoted 13 lines · Arnaldo Carvalho de Melo

Quoted 6 lines

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

Quoted 6 lines

Quoted 4 lines

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

Quoted 1 line

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 :-\

From: Jiri Olsa <[email protected]>

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/[email protected] open here

Signed-off-by Jiri Olsa <[email protected]>

---
 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(-)

tools/perf/Makefile.config +2 -0

index f6786fa2419f..5e3734e4c1e4 100644
@@ -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

tools/perf/scripts/perl/Perf-Trace-Util/Build +1 -1

index 34faecf774ae..ff9a452677fc 100644
@@ -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

tools/perf/scripts/python/Perf-Trace-Util/Build +1 -1

index aefc15c9444a..cd4da129c017 100644
@@ -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

tools/perf/util/block-range.c +1 -1

index f1451c987eec..ff76d5f1d96f 100644
@@ -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(&block_ranges.root); rb; rb = rb_next(rb)) {
 		struct block_range *entry = rb_entry(rb, struct block_range, node);

tools/perf/util/scripting-engines/Build +2 -2

index 82d28c67e0f3..38cd25ce1503 100644
@@ -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 -Wno-shadow

Signature · 1 line

2.13.6

Hi Jiri,

Quoted 19 lines · Jiri Olsa

From: Jiri Olsa <[email protected]>

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

Quoted 4 lines

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?)

Quoted 22 lines · Namhyung Kim

Hi Jiri,

Quoted 19 lines · Jiri Olsa

From: Jiri Olsa <[email protected]>

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

Quoted 7 lines

Quoted 4 lines

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}}}}}}

Quoted 35 lines · Namhyung Kim

Quoted 22 lines

Hi Jiri,

Quoted 19 lines · Jiri Olsa

From: Jiri Olsa <[email protected]>

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

Quoted 7 lines

Quoted 4 lines

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}}}

Quoted 7 lines

*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

Em Mon, Dec 04, 2017 at 09:24:37AM +0100, Jiri Olsa escreveu:

Quoted 45 lines · Jiri Olsa

Quoted 35 lines · Namhyung Kim

Quoted 22 lines

Hi Jiri,

Quoted 19 lines · Jiri Olsa

From: Jiri Olsa <[email protected]>

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

Quoted 7 lines

Quoted 4 lines

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}}}

Quoted 7 lines

*link:
+ -z now

# cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}

Quoted 4 lines

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 :-)

There's no user of those.

Link http://lkml.kernel.org/n/[email protected] open here

Signed-off-by Jiri Olsa <[email protected]>

---
 tools/perf/Makefile.config | 2 --
 1 file changed, 2 deletions(-)

tools/perf/Makefile.config +0 -2

index 5e3734e4c1e4..caa7fe26efa9 100644
@@ -187,7 +187,6 @@ ifdef PYTHON_CONFIG
   ifeq ($(CC_NO_CLANG), 1)
     PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS))
   endif
-  FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
 endif
 
 FEATURE_CHECK_CFLAGS-libpython := $(PYTHON_EMBED_CCOPTS)

@@ -580,7 +579,6 @@ 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)
-  FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
 
   ifneq ($(feature-libperl), 1)
     CFLAGS += -DNO_LIBPERL

Signature · 1 line

2.13.6

Em Wed, Nov 08, 2017 at 11:27:39AM +0100, Jiri Olsa escreveu:

Quoted 1 line

There's no user of those.

[acme@jouet linux]$ find tools/ -type f | xargs grep FLAGS_PYTHON_EMBED tools/perf/Makefile.config: FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
tools/build/feature/Makefile: $(BUILD) -fstack-protector-all -O2 -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lelf -laudit -I/usr/include/slang -lslang $(shell $(PKG_CONFIG) --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl -lz -llzma
tools/build/feature/Makefile: $(BUILD) $(FLAGS_PYTHON_EMBED)
[acme@jouet linux]$

Should we remove these?

- Arnaldo

Quoted 28 lines

Link http://lkml.kernel.org/n/[email protected] open here

Signed-off-by Jiri Olsa <[email protected]>

---
 tools/perf/Makefile.config | 2 --
 1 file changed, 2 deletions(-)

tools/perf/Makefile.config +0 -2

index 5e3734e4c1e4..caa7fe26efa9 100644
@@ -187,7 +187,6 @@ ifdef PYTHON_CONFIG
   ifeq ($(CC_NO_CLANG), 1)
     PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS))
   endif
-  FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
 endif
 
 FEATURE_CHECK_CFLAGS-libpython := $(PYTHON_EMBED_CCOPTS)

@@ -580,7 +579,6 @@ 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)
-  FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
 
   ifneq ($(feature-libperl), 1)
     CFLAGS += -DNO_LIBPERL

Signature · 1 line

2.13.6

Quoted 9 lines

Em Wed, Nov 08, 2017 at 11:27:39AM +0100, Jiri Olsa escreveu:

Quoted 1 line

There's no user of those.

[acme@jouet linux]$ find tools/ -type f | xargs grep FLAGS_PYTHON_EMBED tools/perf/Makefile.config: FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
tools/build/feature/Makefile: $(BUILD) -fstack-protector-all -O2 -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lelf -laudit -I/usr/include/slang -lslang $(shell $(PKG_CONFIG) --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl -lz -llzma
tools/build/feature/Makefile: $(BUILD) $(FLAGS_PYTHON_EMBED)
[acme@jouet linux]$

Quoted 1 line

Should we remove these?

oops, missed that directory.. thos eneed to stay then ;-) sry