From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
David Ahern <dsahern@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH 2/3] perf tools: Fix build for hardened environments
Date: Thu, 23 Nov 2017 11:15:32 -0300 [thread overview]
Message-ID: <20171123141532.GA8789@kernel.org> (raw)
In-Reply-To: <20171110094325.GA18088@krava>
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 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'
next prev parent reply other threads:[~2017-11-23 14:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-08 10:27 [PATCH 0/3] perf tools: Build fixes Jiri Olsa
2017-11-08 10:27 ` [PATCH 1/3] perf tools: Use shell function for perl cflags retrieval Jiri Olsa
2017-11-08 16:03 ` Arnaldo Carvalho de Melo
2017-11-18 8:26 ` [tip:perf/core] " tip-bot for Jiri Olsa
2017-12-18 17:15 ` [tip:perf/urgent] " tip-bot for Jiri Olsa
2017-11-08 10:27 ` [PATCH 2/3] perf tools: Fix build for hardened environments Jiri Olsa
2017-11-08 16:03 ` Arnaldo Carvalho de Melo
2017-11-09 7:36 ` Jiri Olsa
2017-11-09 12:52 ` Arnaldo Carvalho de Melo
2017-11-10 9:43 ` Jiri Olsa
2017-11-23 14:15 ` Arnaldo Carvalho de Melo [this message]
2017-11-23 14:38 ` Jiri Olsa
2017-11-29 19:54 ` Arnaldo Carvalho de Melo
2017-11-29 20:00 ` Arnaldo Carvalho de Melo
2017-11-30 10:08 ` Jiri Olsa
2017-12-01 2:11 ` Namhyung Kim
2017-12-04 7:34 ` Jiri Olsa
2017-12-04 8:24 ` Jiri Olsa
2017-12-04 15:35 ` Arnaldo Carvalho de Melo
2017-12-05 16:19 ` Jiri Olsa
2017-12-06 16:40 ` [tip:perf/core] perf tools: Fix up build in hardnened environments tip-bot for Jiri Olsa
2017-12-18 17:16 ` [tip:perf/urgent] perf tools: Fix up build in hardened environments tip-bot for Jiri Olsa
2017-11-08 10:27 ` [PATCH 3/3] perf tools: Removing FLAGS_PYTHON_EMBED/FLAGS_PERL_EMBED variables Jiri Olsa
2017-11-08 16:06 ` Arnaldo Carvalho de Melo
2017-11-09 7:27 ` Jiri Olsa
2017-11-09 12:48 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171123141532.GA8789@kernel.org \
--to=acme@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=dsahern@gmail.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.