All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael S. Zick <minimod@morethan.org>
To: buildroot@busybox.net
Subject: [Buildroot] Can't use output/host/ as "SDK" with external toolchain
Date: Wed, 11 Jan 2012 08:19:58 -0600	[thread overview]
Message-ID: <201201110820.00566.minimod@morethan.org> (raw)
In-Reply-To: <CAAXf6LVOnJ25zLqdBwoLXX0XORPwNp_pGab_+6xB9Zsi2TJhig@mail.gmail.com>

On Wed January 11 2012, Thomas De Schampheleire wrote:
> On Tue, Jan 10, 2012 at 9:22 PM, Bryce Schober <bryce.schober@gmail.com> wrote:
> > As I said in my original post, I am using an externally generated and
> > configured (and statically linked) crosstool-ng toolchain.
> 
> I'm sorry, I read over that part.
> 
> > I believe that it
> > is the buildroot import thereof that is at fault. Again, in summary:
> > 1. Buildroot generates absolute-pathed symbolic links to the external
> > binutils in output/host/usr/bin instead of copying them in.
> > 2. Buildroot's ext-toolchain-wrapper uses an absolute path for its sysroot
> > configuration.
> > 3. Buildroot's ext-toolchain-wrapper uses?an?absolute path for its binary
> > exec path.
> >
> > I realize that these problems are triggered by my specification of:
> > BR2_TOOLCHAIN_EXTERNAL_PATH="$(TOPDIR)/../my-ext-toolchain-dir/"
> > But I can't specify merely "../my-ext-toolchain-dir/" without breaking
> > things either.
> >
> 
> Have you tried using BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD instead? This
> requires you to archive the crosstool-ng toolchain and specify it to
> buildroot. Buildroot will then extract it and unpack. The binutils
> will be copied in this case, and not symlinked.
> 
> This is not possibly in stock buildroot. I have submitted patches for
> this a while ago, but they are not yet included. I think there was a
> comment by Thomas that I still have to fix. In the mean time, try
> using patches 1 and 2 of the following series:
> http://lists.busybox.net/pipermail/buildroot/2011-August/044779.html
>

The best kind of 'bump' for things in the "Pending" box,
somebody needs it. 

Shall we invent a 'Needed-by: ... ' attribute for the pending patches?

Mike
> Best regards,
> Thomas
> 
> 
> >
> > On Tue, Jan 10, 2012 at 3:26 AM, Thomas De Schampheleire
> > <patrickdepinguin+buildroot@gmail.com> wrote:
> >>
> >> Hi Bryce,
> >>
> >> On Mon, Jan 9, 2012 at 11:54 PM, Bryce Schober <bryce.schober@gmail.com>
> >> wrote:
> >> > What I mean by "SDK" is the ability to compile external programs using
> >> > the
> >> > buildroot toolchain and libraries on any reasonably-compatible host. I'm
> >> > assuming that the toolchain itself is built properly static for its own
> >> > host
> >> > independence (which in my case, it is).?Ideally the toolchain in the
> >> > output/host directory would be capable of standing alone, when built
> >> > properly
> >> >
> >> > I'm having two issues w/ archving the?output/host dir for extraction and
> >> > usage in a different host directory. I'm using a custom-built
> >> > crosstool-ng
> >> > built externally and independent of buildroot.
> >> >
> >> > The external toolchain import results in three distinct problems that I
> >> > can
> >> > see:
> >> > 1. The symbolic links for binutils binaries in use absolute paths to
> >> > link to
> >> > the external toolchain instead of copying them in.
> >> > 2. The ext-toolchain-wrapper uses an absolute path for the sysroot
> >> > directory.
> >> > 3. The ext-toolchain-wrapper seems to point to the old (import-from) bin
> >> > directory, not the path to which the toolchain has been copied.
> >> >
> >> > I'm not particularly familiar with the relocatability of toolchains or
> >> > buildroot's method thereof, and so am not sure where to start with a
> >> > proposal, let alone a patch. If I could get some direction as to how
> >> > best to
> >> > tackle this, I'd be grateful.
> >>
> >> It is known that the toolchains generated by buildroot are not
> >> relocatable.
> >> However, you can tell buildroot to create the toolchain with
> >> crosstool-ng, and this one is relocatable. I suggest you give that a
> >> try to see if it solves your problems.
> >> I'm using buildroot in the same way and it works fine for me.
> >>
> >> Best regards,
> >> Thomas
> >
> >
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 

  reply	other threads:[~2012-01-11 14:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-09 22:54 [Buildroot] Can't use output/host/ as "SDK" with external toolchain Bryce Schober
2012-01-10 11:26 ` Thomas De Schampheleire
2012-01-10 20:22   ` Bryce Schober
2012-01-11  7:38     ` Thomas De Schampheleire
2012-01-11 14:19       ` Michael S. Zick [this message]
2012-01-11 19:49       ` Bryce Schober
2012-01-11 23:03         ` Peter Korsgaard
2012-01-12  9:17 ` 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=201201110820.00566.minimod@morethan.org \
    --to=minimod@morethan.org \
    --cc=buildroot@busybox.net \
    /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.