All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
Date: Tue, 15 Sep 2015 09:35:23 +0200	[thread overview]
Message-ID: <20150915093523.0597731f@free-electrons.com> (raw)
In-Reply-To: <CAOudHSVcePTAq7PLON-0Zig-JkJtTNnu-RzHtkYf0f00pe8atw@mail.gmail.com>

Hello,

On Tue, 15 Sep 2015 00:06:46 -0400, Cjw X wrote:
> So, I'm going through comments and investigating. Everything seems
> pretty reasonable.

Great, thanks.

> >>  # Compute GNU_TARGET_NAME
> >> +ifeq ($(BR2_TOOLCHAIN_NO_VENDOR),y)
> >> +GNU_TARGET_NAME = $(ARCH)-$(TARGET_OS)-$(LIBC)$(ABI)
> >
> > Is it really mandatory to *not* have a vendor part of the tuple?
> 
> I've tried building arm-buildroot-none-eabi and
> arm-buildroot-none-newlibeabi, both of which, based on my
> understanding, should compile, but none of the tools build with that
> target. Binutils doesn't compile, nor does gcc. I spent some time
> looking at this, but never found an elegant solution.

Interesting. I guess we'll have to experiment a bit with this.

I'm adding Yann in Cc. Yann, have you experienced such thing when
adding bare-metal/newlib support in Crosstool-NG? I've quickly looked
at the Crosstool-NG code, and I don't see the vendor part of the tuple
being skipped specifically for bare metal/newlib toolchains, but maybe
I missed it.

Thanks,

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

  reply	other threads:[~2015-09-15  7:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-13  7:02 [Buildroot] [PATCH 1/3] Experimental addition of the newlib library Chris Wardman
2015-09-13  7:02 ` [Buildroot] [PATCH 2/3] New entry for the Cortex-M4 processor Chris Wardman
2015-09-13  8:21   ` Thomas Petazzoni
2015-09-15 20:52     ` Yann E. MORIN
2015-09-24 21:02       ` Peter Korsgaard
2015-09-13  7:02 ` [Buildroot] [PATCH 3/3] Adding support for uclibcpp library Chris Wardman
2015-09-13 22:00   ` Thomas Petazzoni
2015-09-17  7:07     ` Cjw X
2015-09-17  7:25       ` Thomas Petazzoni
2015-09-13  8:17 ` [Buildroot] [PATCH 1/3] Experimental addition of the newlib library Thomas Petazzoni
2015-09-15  4:06   ` Cjw X
2015-09-15  7:35     ` Thomas Petazzoni [this message]
2015-09-15 17:53       ` Yann E. MORIN
2015-09-15 19:39         ` Thomas Petazzoni
2015-09-24 21:30           ` Peter Korsgaard
2015-09-25  7:30             ` Thomas Petazzoni
2015-09-27 16:40               ` Cjw X
2015-09-15 20:45   ` Yann E. MORIN
     [not found]     ` <CAOudHSVLKiTwrkv0xBNVW=ry3w1yOv4TJqP8+JMFSJRzw3dASQ@mail.gmail.com>
2015-09-16 17:07       ` Yann E. MORIN
2015-09-16 17:36   ` Cjw X
2015-09-16 17:38     ` Thomas Petazzoni
2015-09-15 20:41 ` Yann E. MORIN
2015-09-17  7:41   ` Cjw X

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=20150915093523.0597731f@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.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.