public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: "mpe@ellerman.id.au" <mpe@ellerman.id.au>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"Vineet.Gupta1@synopsys.com" <Vineet.Gupta1@synopsys.com>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"mmarek@suse.cz" <mmarek@suse.cz>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>
Subject: Re: Build regressions/improvements in v4.9-rc1
Date: Wed, 19 Oct 2016 22:32:00 +0200	[thread overview]
Message-ID: <20161019223200.21003f60@free-electrons.com> (raw)
In-Reply-To: <1476879762.26312.12.camel@synopsys.com>

Hello,

On Wed, 19 Oct 2016 12:23:12 +0000, Alexey Brodkin wrote:

> > I tried building a new toolchain with buildroot, using the instructions
> > from last time, but the resulting toolchain doesn't relocate, ie. it has
> > hard-coded paths in it. Any ideas?  
> 
> Hm... that's strange - it used to work but doesn't work with newer Buildroot...
> 
> Anyways if something very simple (i.e. with no extra libraries) works for you just go
> ahead and grab pre-built image that Thomas Petazzoni builds.
> 
> That's the most recent one:
> http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2
> 
> If I'm not mistaken Thomas runs some post-processing script to make these toolchains
> relocatable.
> 
> Maybe Thomas may comment on that and even maybe will share his post-processing technique
> so you'll be able to build your customized toolchain.

I simply have two patches on top of Buildroot to build the toolchains
available at http://autobuild.buildroot.org/toolchains/tarballs/ :

 - One patch that builds mpc, gmp and mpfr statically. This is needed
   since the host tools are built with an absolute rpath, so once the
   toolchain is moved, it can't find the host shared libraries that
   have been built for it. Using static linking is a temporary
   work-around, our idea is to fix the rpath to use relative path using
   $ORIGIN. There are some patches from Samuel Martin doing this, we
   have discussed them during the Buildroot Developers Meeting last
   week-end, and we proposed to Samuel to investigate a slightly
   different approach (namely add more features to the upstream
   patchelf utility).

 - One patch that fixes the toolchain wrapper logic so that it works
   fine when the toolchain is moved out of the usr/ sub-directory. We
   started discussing it during the meeting, but I got drowned into
   other discussions, so we haven't had the time to get to the bottom
   of it.

If people are interested, I can prepare a tutorial on how to build
re-usable and relocatable toolchains with Buildroot.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2016-10-19 20:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17  7:21 Build regressions/improvements in v4.9-rc1 Geert Uytterhoeven
2016-10-17  7:34 ` Geert Uytterhoeven
2016-10-17 16:59   ` Vineet Gupta
2016-10-17 21:02     ` Arnd Bergmann
2016-10-17 22:37       ` Vineet Gupta
2016-10-19 11:50         ` Michael Ellerman
2016-10-19 12:23           ` Alexey Brodkin
2016-10-19 20:32             ` Thomas Petazzoni [this message]
2016-10-26 23:56             ` Michael Ellerman
2016-10-27  7:07               ` Thomas Petazzoni
2016-10-27  9:07                 ` Alexey Brodkin
2016-10-27  9:11                   ` Thomas Petazzoni
2016-10-27  9:24                     ` Geert Uytterhoeven
2016-10-27  9:39                       ` Alexey Brodkin
2016-10-27 17:21                         ` Vineet Gupta
2016-10-28 10:42                           ` Arnd Bergmann
2016-10-27  9:32                     ` Arnd Bergmann
2016-10-27 10:04                       ` Thomas Petazzoni

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=20161019223200.21003f60@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=Vineet.Gupta1@synopsys.com \
    --cc=arnd@arndb.de \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=mmarek@suse.cz \
    --cc=mpe@ellerman.id.au \
    --cc=peterz@infradead.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