From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754569AbdKIMwQ (ORCPT ); Thu, 9 Nov 2017 07:52:16 -0500 Received: from mail.kernel.org ([198.145.29.99]:48678 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752678AbdKIMwO (ORCPT ); Thu, 9 Nov 2017 07:52:14 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3BB1218BB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=acme@kernel.org Date: Thu, 9 Nov 2017 09:52:12 -0300 From: Arnaldo Carvalho de Melo To: Jiri Olsa Cc: Jiri Olsa , lkml , Ingo Molnar , Namhyung Kim , David Ahern , Peter Zijlstra Subject: Re: [PATCH 2/3] perf tools: Fix build for hardened environments Message-ID: <20171109125212.GG4333@kernel.org> References: <20171108102739.30338-1-jolsa@kernel.org> <20171108102739.30338-3-jolsa@kernel.org> <20171108160321.GC4333@kernel.org> <20171109073622.GB14419@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171109073622.GB14419@krava> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 (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