All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [arc-buildroot] Toolchain issues on multiple architectures
Date: Fri, 11 Sep 2020 10:28:13 +0200	[thread overview]
Message-ID: <20200911102813.7dc2153f@windsurf.hq.k.grp> (raw)
In-Reply-To: <BN8PR12MB3330260C7D57EE97065A5DC0A1270@BN8PR12MB3330.namprd12.prod.outlook.com>

Hello,

On Thu, 10 Sep 2020 16:39:18 +0000
Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:

> > Issue is caused by the recent version of gdb, where gdbserver has been
> > moved from gdb/gdbserver/ to gdbserver/. However, the story is not so
> > simple: you can't simply go in gdbserver/ and run ./configure from it,
> > that doesn't work anymore.  
> 
> But in your exercise mentioned above do you really need only gdbserver?
> I understand that full GDB might be quite an overkill for a tiny target but
> it might not be installed onto the target rootfs, right?

I'm building cross-compilation toolchains, in which we only want
gdbserver for the target, not the full gdb.

> So what if for GDB 10+ we'll add an installation quirk which will remove
> full GDB from "output/target" if we only want gdbsever?

Building the full blown gdb would also require building its
dependencies, i.e ncurses and possibly libiconv. Building only
gdbserver allows to avoid that.

I've got some feedback from upstream though, they pointed to:

  https://github.com/bminor/binutils-gdb/blob/master/gdbserver/README#L86

which explains what is the supported way of building just gdbserver.
We'll have to test this, and see if it works not only with recent GDB,
but also older GDB versions that we still support.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2020-09-11  8:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10 10:05 [Buildroot] Toolchain issues on multiple architectures Thomas Petazzoni
2020-09-10 14:43 ` Matthew Weber
2020-09-10 15:43   ` Thomas Petazzoni
2020-09-10 15:43   ` Matthew Weber
2020-09-10 16:55     ` Matthew Weber
2020-09-11 12:43       ` Matthew Weber
2020-09-10 16:39 ` [Buildroot] [arc-buildroot] " Alexey Brodkin
2020-09-11  8:28   ` Thomas Petazzoni [this message]
2020-09-11  9:59     ` Alexey Brodkin
2020-09-10 23:17 ` [Buildroot] " Alistair Francis
2020-09-11  7:30   ` Thomas Petazzoni
2020-09-11 16:03     ` Alistair Francis
2020-09-24  9:42       ` Thomas Petazzoni
2020-09-24 18:20         ` Alistair Francis
2020-09-24 18:47           ` Thomas Petazzoni
2020-09-24 18:47             ` Alistair Francis
2020-09-24 18:28         ` Bernd Kuhls
2020-09-25  9:30 ` Romain Naour

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=20200911102813.7dc2153f@windsurf.hq.k.grp \
    --to=thomas.petazzoni@bootlin.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.