From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
Date: Sun, 13 Sep 2015 10:17:38 +0200 [thread overview]
Message-ID: <20150913101738.238ebc06@free-electrons.com> (raw)
In-Reply-To: <1442127768-26447-1-git-send-email-cjwfirmware@vxmdesign.com>
Chris,
Thanks a lot! This patch looks pretty good. I have a couple of comments
below, but overall it looks nice.
On Sun, 13 Sep 2015 03:02:46 -0400, Chris Wardman wrote:
> This patch add support for a newlib library build of the gcc toolchain.
> This is designed to build arm-none-eabi- toolchain, and it was tested against an stm32f4discovery board.
>
> Hopefully this will help people build bare metal code for arm processors
A few comments on the commit log:
* The title should be something like:
toolchain: add support for the newlib library
* The commit log text should be line wrapped at ~80 columns.
* I believe the last sentence "Hopefully this will help people build
bare metal code for arm processors" is not really useful as part of
the commit log.
> diff --git a/package/Makefile.in b/package/Makefile.in
> index 545694f..7f4d74e 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -37,10 +37,16 @@ $(error BR2_TOOLCHAIN_BUILDROOT_VENDOR cannot be 'unknown'. \
> endif
>
> # 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?
> diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
> index 501fcea..62f6b80 100644
> --- a/package/gcc/gcc.mk
> +++ b/package/gcc/gcc.mk
> @@ -100,6 +100,13 @@ HOST_GCC_COMMON_CONF_OPTS = \
> HOST_GCC_COMMON_CONF_ENV = \
> MAKEINFO=missing
>
> +ifeq ($(BR2_TOOLCHAIN_BUILDROOT_NEWLIB),y)
> +HOST_GCC_COMMON_CONF_OPTS += --with-gnu-as
> +else
> +HOST_GCC_COMMON_CONF_OPTS += --disable-__cxa_atexit
> +endif
While I may understand that you're adding some specific options when
BR2_TOOLCHAIN_BUILDROOT_NEWLIB=y, could you explain why you're doing
something new in the "else" case, which should already be working today?
> +
> +
Only one empty new line is necessary here.
> GCC_COMMON_TARGET_CFLAGS = $(TARGET_CFLAGS)
> GCC_COMMON_TARGET_CXXFLAGS = $(TARGET_CXXFLAGS)
>
> diff --git a/package/newlib/Config.in b/package/newlib/Config.in
> new file mode 100644
> index 0000000..0f3e2d7
> --- /dev/null
> +++ b/package/newlib/Config.in
> @@ -0,0 +1,4 @@
> +config BR2_PACKAGE_NEWLIB
> + bool
> + depends on BR2_TOOLCHAIN_USES_NEWLIB
> + default y
Use tab for the indentation of bool / depends on / default.
> diff --git a/package/newlib/newlib-0001-configure-tooldir-path.patch b/package/newlib/newlib-0001-configure-tooldir-path.patch
> new file mode 100644
> index 0000000..c162678
> --- /dev/null
> +++ b/package/newlib/newlib-0001-configure-tooldir-path.patch
> @@ -0,0 +1,25 @@
> +This patch is required to fix how the newlib headers are installed.
> +
> +The cross compiler expects headers to be in
> +.../host/usr/arm-none-eabi/sysroot/usr/include/newlib.h
> +by default newlib installed the headers into
> +.../host/usr/arm-none-eabi/sysroot/arm-none-eabi/include/newlib.h
> +
> +${exec_prefix} provides the .../host/usr/arm-none-eabi/sysroot path
> +${target_noncanonical} provides an extra arm-none-eabi/ that must be removed.
> +
> +Signed-off-by: Chris Wardman <cjwfirmware@vxmdesign.com>
> +
> +
> +diff -uNr newlib-old/configure newlib-new/configure
> +--- newlib-old/configure 2014-07-05 17:09:07.000000000 -0400
> ++++ newlib-new/configure 2014-12-25 00:59:01.727549186 -0500
> +@@ -6985,7 +6985,7 @@
> +
> + # Some systems (e.g., one of the i386-aix systems the gas testers are
> + # using) don't handle "\$" correctly, so don't use it here.
> +-tooldir='${exec_prefix}'/${target_noncanonical}
> ++tooldir='${exec_prefix}'/usr
> + build_tooldir=${tooldir}
You're patching the configure script, which we generally don't like,
since it's generated from configure.ac. So you should either patch
configure.ac and use NEWLIB_AUTORECONF = YES, or alternatively don't
patch the code, and instead use a post install hook to move around the
headers.
> diff --git a/package/newlib/newlib.mk b/package/newlib/newlib.mk
> new file mode 100644
> index 0000000..02008e5
> --- /dev/null
> +++ b/package/newlib/newlib.mk
> @@ -0,0 +1,48 @@
> +################################################################################
> +#
> +# newlib
> +#
> +################################################################################
> +
> +NEWLIB_VERSION = 2.2.0
There's a 2.2.0-1 version, that was released after 2.2.0, so presumably
we may want to use this newer version?
> +NEWLIB_SITE = ftp://sourceware.org/pub/newlib
> +NEWLIB_LICENSE = MIT
> +NEWLIB_LICENSE_FILES = COPYRIGHT
> +
> +NEWLIB_DEPENDENCIES = host-gcc-initial
> +NEWLIB_ADD_TOOLCHAIN_DEPENDENCY = NO
> +NEWLIB_INSTALL_STAGING = YES
> +
> +define NEWLIB_CONFIGURE_CMDS
> + (cd $(@D); \
> + $(TARGET_MAKE_ENV) \
> + ./configure \
> + --target=$(GNU_TARGET_NAME) \
> + --host=$(GNU_HOST_NAME) \
> + --build=$(GNU_HOST_NAME) \
> + --prefix=$(STAGING_DIR) \
> + --includedir=$(STAGING_DIR)/usr/include \
> + --oldincludedir=$(STAGING_DIR)/usr/include \
> + --with-build-sysroot=$(STAGING_DIR) \
> + --enable-newlib-io-long-long \
> + --enable-newlib-register-fini \
> + --disable-newlib-supplied-syscalls \
> + --disable-nls)
Why don't you use the autotools-package infrastructure? newlib is using
autoconf, so I believe it does make sense to use the autotools-package
infrastructure.
> +define NEWLIB_APPLY_PATCHES
> + $(APPLY_PATCHES) $(@D) package/newlib \*.patch
> +endef
This does not have any effect, and is not necessary: patches in
package/<pkg>/ are automatically applied.
> +define NEWLIB_BUILD_CMDS
> + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)
> +endef
Not needed if you use the autotools-package infrastructure.
> +define NEWLIB_INSTALL_STAGING_CMDS
> + mkdir -p $(HOST_DIR)/usr/$(GNU_TARGET_NAME)/lib
> + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) install
Except the mkdir, the install command is not needed if you use the
autotools-package infrastructure.
Thanks a lot!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-09-13 8:17 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 ` Thomas Petazzoni [this message]
2015-09-15 4:06 ` [Buildroot] [PATCH 1/3] Experimental addition of the newlib library Cjw X
2015-09-15 7:35 ` Thomas Petazzoni
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=20150913101738.238ebc06@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.