[Buildroot] [PATCH 1/3] Experimental addition of the newlib library
Yann E. MORIN
yann.morin.1998 at free.fr
Tue Sep 15 17:53:54 UTC 2015
Thomas, Cjw, All,
On 2015-09-15 09:35 +0200, Thomas Petazzoni spake thusly:
> On Tue, 15 Sep 2015 00:06:46 -0400, Cjw X wrote:
> > >> # 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.
In fact, that's not the 'vendor' part that is to be removed; it's the
'kernel' part.
A canonical tuple is usually a three-part tuple: arch-vendor-os. But in
the case of linux, the 'os' field is split in two: the 'kernel' and
'userland', like so: arch-vendor-kernel-userland.
But really, the 'os' or 'userland' fields mostly denote the ABI being
used.
So we end up with things like:
- targets for running Linux:
- i386-blabla-linux-gnu
- powerpc-unknown-linux-gnuspe
- arm-none-linux-gnueabihf
- and so on...
- targets running bare-metal:
- i386-blabla-elf
- powerpc-unknown-spe
- arm-none-eabihf
- and so on...
So, for bare-metal:
- tuples are made of only three-part (in fact the historical canonical
form),
- the part that is "omitted" from the four-part variant is not the
vendor string; rather the 'kernel' and 'userland' fields are merged
into one.
However, I'm not sure it is possible to run newlib as the C library
under Linux (i.e. as a replacement for glibc/uClibc/musl). IIRC, newlib
really targets kernel-less systems. It seems there are linux support
files in the newlib source, but I doubt tht is often tested or even
compeltely supported; a cursory look at the interwebs does not return
promissing results...
And in nay case, I'm afraid a lot of packages would not build against
newlib.
All that to say that I need to look at the patch, and I otherwise do not
see the point for having newlib in Buildroot...
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list