public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
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, 9 Nov 2017 08:36:22 +0100	[thread overview]
Message-ID: <20171109073622.GB14419@krava> (raw)
In-Reply-To: <20171108160321.GC4333@kernel.org>

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 <jolsa@redhat.com>
> > 
> > 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 (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

  reply	other threads:[~2017-11-09  7:36 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 [this message]
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
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=20171109073622.GB14419@krava \
    --to=jolsa@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=dsahern@gmail.com \
    --cc=jolsa@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox