Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Trent Piepho <tpiepho@impinj.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] toolchain-external: Fix paths in libstdc++ gdb python file
Date: Mon, 1 Apr 2019 17:32:37 +0000	[thread overview]
Message-ID: <1554139955.7410.73.camel@impinj.com> (raw)
In-Reply-To: <20190331144231.13d5b9ca@windsurf>

On Sun, 2019-03-31 at 14:42 +0200, Thomas Petazzoni wrote:
> 
> > The python file libstdc++.so.6.0.25-gdb.py contains two paths:
> > pythondir = '/share/gcc-8.2.1/python'
> > libdir = '/arm-linux-gnueabihf/lib'
> > 
> > The latter is the location of the file in the toolchain and the
> > former
> > the location of a python module to be used by gdb.  The python code
> > in
> > the file subtracts libdir from the end of the current
> > libstdc++.so.6.0.25-gdb.py location and appends pythondir, to find
> > the
> > current path to the python module.
> > 
> > Buildroot installs this file into the stage, at which point the
> > paths
> > above are no longer correct.
> > 
> > This patch uses sed to fixup the paths to reflect the installed
> > location, relative to HOST_DIR, and the location of the python
> > module
> > relative to HOST_DIR.
> > 
> > and
> 
> And ?

and that's a stray and from a squashed commit I didn't notice.

> Is this problem specific to the ARM ARM toolchain ? I guess other
> toolchains will have the same file, so probably we want a more
> generic
> fix ?

I checked the Linaro ARM 2018.05 toolchain, similar problem, but worse.

pythondir = '/home/tcwg-buildslave/workspace/tcwg-make-
release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-
gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu/share/gcc-
7.3.1/python'
libdir = '/home/tcwg-buildslave/workspace/tcwg-make-
release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-
gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu/arm-linux-
gnueabihf/lib'

Path isn't correct at all.  At least the ARM toolchain is ok until
buildroot moves some files around.

I was able to modify my sed script a bit so that it works on this
toolchain too.  The two variables I added in the patch have different
values for this toolchain of course.  That's why I put them there. 
What would be the place to put in a common hook like this?

      reply	other threads:[~2019-04-01 17:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-29 22:04 [Buildroot] [PATCH] toolchain-external: Fix paths in libstdc++ gdb python file Trent Piepho
2019-03-29 22:11 ` Trent Piepho
2019-03-31 12:42 ` Thomas Petazzoni
2019-04-01 17:32   ` Trent Piepho [this message]

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=1554139955.7410.73.camel@impinj.com \
    --to=tpiepho@impinj.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox