All of lore.kernel.org
 help / color / mirror / Atom feed
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'

  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.