All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Wagner <will_wagner@carallon.com>
To: buildroot@busybox.net
Subject: [Buildroot] external toolchain question
Date: Thu, 16 Sep 2010 12:41:09 +0100	[thread overview]
Message-ID: <4C920255.80602@carallon.com> (raw)
In-Reply-To: <20100916110442.29178d68@surf>

  On 16/09/2010 10:04, Thomas Petazzoni wrote:
> On Thu, 16 Sep 2010 09:03:11 +0100
> William Wagner<will_wagner@carallon.com>  wrote:
>
>> With libstdc++ in /usr/lib on target but /lib in staging I was
>> getting an error in gdb when it tried to load libstdc++, moving the
>> library fixed the problem.
> Hum, right, ok.
>
> The old behaviour was to find each library in staging/ and then copy it
> to the same location in target/. Unfortunately, it was causing problems
> with Buildroot toolchains, because in those, libstdc++ was neither in
> lib/ or in usr/lib, but in usr/<tuple>/lib. Therefore, I moved to a
> strategy that consists in having a fixed destination for the library on
> the target filesystem. This was implemented by
> ecb7642cce36bc68d93f0eee677adc7da538228d.
>
> However, later on, to fix other issues, also related to libstdc++, I
> modified the build procedure for Buildroot toolchains so that a
> <tuple>/lib ->  lib/ is created, as other toolchain building systems are
> doing. This was implemented in
> 3c77bab2eeace3ee675bd745ca335fa3dd1630bb. The result is that libstdc++
> is back into a usual location in Buildroot toolchains, so we could in
> fact more or less revert ecb7642cce36bc68d93f0eee677adc7da538228d and
> make sure that libraries are at the same location in both staging/ and
> target/. I'll cook a patch for this.

Have now also tried a code sourcery toolchain which puts libstdc++ in 
/usr/lib and if they don't match again get the error.

We could change copy_toolchain_lib_root so that it puts the libraries in 
the corresponding location it finds them in rather than currently 
searching in three locations but always copying to the specified one.

> Thanks for the report!
>
> Thomas

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

  reply	other threads:[~2010-09-16 11:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15 18:17 [Buildroot] external toolchain question William Wagner
2010-09-15 18:40 ` Marcus Osdoba
2010-09-15 18:50   ` Yann E. MORIN
2010-09-15 19:33     ` Marcus Osdoba
2010-09-15 20:46       ` Yann E. MORIN
2010-09-15 19:19 ` Thomas Petazzoni
2010-09-16  8:03   ` William Wagner
2010-09-16  9:04     ` Thomas Petazzoni
2010-09-16 11:41       ` William Wagner [this message]
2010-09-16 12:14         ` 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=4C920255.80602@carallon.com \
    --to=will_wagner@carallon.com \
    --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.