* [Buildroot] [PATCH 2/3] New entry for the Cortex-M4 processor
2015-09-13 7:02 [Buildroot] [PATCH 1/3] Experimental addition of the newlib library Chris Wardman
@ 2015-09-13 7:02 ` Chris Wardman
2015-09-13 8:21 ` Thomas Petazzoni
2015-09-13 7:02 ` [Buildroot] [PATCH 3/3] Adding support for uclibcpp library Chris Wardman
` (2 subsequent siblings)
3 siblings, 1 reply; 23+ messages in thread
From: Chris Wardman @ 2015-09-13 7:02 UTC (permalink / raw)
To: buildroot
I created a new entry for the Cortex-M4 processor in the processor list.
Right now it is being tested against a STM32F4disovery board.
This is technically an M4F. I will add that entry with the floating point in the future
Signed-off-by: Chris Wardman <cjwfirmware@vxmdesign.com>
---
arch/Config.in.arm | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 4d10f4c..2692402 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -156,6 +156,11 @@ config BR2_cortex_m3
bool "cortex-M3"
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_HAS_THUMB2
+config BR2_cortex_m4
+ bool "cortex-M4"
+ select BR2_ARM_CPU_HAS_THUMB
+ select BR2_ARM_CPU_HAR_THUMB2
+ select BR2_ARM_CPU_ARMV7M
config BR2_fa526
bool "fa526/626"
select BR2_ARM_CPU_HAS_ARM
@@ -419,6 +424,7 @@ config BR2_GCC_TARGET_CPU
default "cortex-a12" if BR2_cortex_a12
default "cortex-a15" if BR2_cortex_a15
default "cortex-m3" if BR2_cortex_m3
+ default "cortex-m4" if BR2_cortex_m4
default "fa526" if BR2_fa526
default "marvell-pj4" if BR2_pj4
default "strongarm" if BR2_strongarm
--
1.9.1
^ permalink raw reply related [flat|nested] 23+ messages in thread* [Buildroot] [PATCH 2/3] New entry for the Cortex-M4 processor
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
0 siblings, 1 reply; 23+ messages in thread
From: Thomas Petazzoni @ 2015-09-13 8:21 UTC (permalink / raw)
To: buildroot
Chris,
On Sun, 13 Sep 2015 03:02:47 -0400, Chris Wardman wrote:
> I created a new entry for the Cortex-M4 processor in the processor list.
Don't use "personal" formulations in commit log. It should be something
like: "This commit adds a new entry..."
> Right now it is being tested against a STM32F4disovery board.
> This is technically an M4F. I will add that entry with the floating point in the future
Ditto here.
And the title of the commit log should be:
arch: add entry for the ARM Cortex-M4 processor
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index 4d10f4c..2692402 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -156,6 +156,11 @@ config BR2_cortex_m3
> bool "cortex-M3"
> select BR2_ARM_CPU_HAS_THUMB
> select BR2_ARM_CPU_HAS_THUMB2
> +config BR2_cortex_m4
> + bool "cortex-M4"
> + select BR2_ARM_CPU_HAS_THUMB
> + select BR2_ARM_CPU_HAR_THUMB2
> + select BR2_ARM_CPU_ARMV7M
Please use tab for indentation. Also, while Cortex-M3 also does it, I
think selecting both Thumb and Thumb-2 is not correct: Cortex-M3/M4
only support Thumb-2, no? Or at least, gcc only provides a -mthumb
option that will generate Thumb-2 code, so there is no way to generate
classic Thumb code on ARMv7-M platforms. Though since the problem
already exists for Cortex-M3, we can keep it this way for Cortex-M4 as
well for now.
Also, you're selecting the BR2_ARM_CPU_ARMV7M option, but this option
does not exist. Since there is a BR2_ARM_CPU_ARMV7A, I believe it makes
sense to create this option, so probably you should have three patches
here:
* One option that adds BR2_ARM_CPU_ARMV7M
* One patch that makes Cortex-M3 select it
* One patch that adds Cortex-M4
Other than that, looks good to me.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 2/3] New entry for the Cortex-M4 processor
2015-09-13 8:21 ` Thomas Petazzoni
@ 2015-09-15 20:52 ` Yann E. MORIN
2015-09-24 21:02 ` Peter Korsgaard
0 siblings, 1 reply; 23+ messages in thread
From: Yann E. MORIN @ 2015-09-15 20:52 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2015-09-13 10:21 +0200, Thomas Petazzoni spake thusly:
> On Sun, 13 Sep 2015 03:02:47 -0400, Chris Wardman wrote:
[--SNIP--]
> > diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> > index 4d10f4c..2692402 100644
> > --- a/arch/Config.in.arm
> > +++ b/arch/Config.in.arm
> > @@ -156,6 +156,11 @@ config BR2_cortex_m3
> > bool "cortex-M3"
> > select BR2_ARM_CPU_HAS_THUMB
> > select BR2_ARM_CPU_HAS_THUMB2
> > +config BR2_cortex_m4
> > + bool "cortex-M4"
> > + select BR2_ARM_CPU_HAS_THUMB
> > + select BR2_ARM_CPU_HAR_THUMB2
> > + select BR2_ARM_CPU_ARMV7M
>
> Please use tab for indentation. Also, while Cortex-M3 also does it, I
> think selecting both Thumb and Thumb-2 is not correct: Cortex-M3/M4
> only support Thumb-2, no? Or at least, gcc only provides a -mthumb
> option that will generate Thumb-2 code, so there is no way to generate
> classic Thumb code on ARMv7-M platforms. Though since the problem
> already exists for Cortex-M3, we can keep it this way for Cortex-M4 as
> well for now.
It is my understanding that -mthumb will generate Thumb2 instructions on
cores that have Thumb2 (e.g. Cortex), and Thumb (aka Thumb1) on cores
that do not have Thumb2.
Also, since Thumb2 is a strict superset of Thumb, then having Thumb2
means having Thumb, at least from an instruction set point of view.
I believe Thumb2 should select Thumb.
What I meant is: if a package needs Thumb (e.g. to use assembly code
that uses Thumb instructions) then that assembly code is still entirely
valid when the core is Thumb2-capable.
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. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 2/3] New entry for the Cortex-M4 processor
2015-09-15 20:52 ` Yann E. MORIN
@ 2015-09-24 21:02 ` Peter Korsgaard
0 siblings, 0 replies; 23+ messages in thread
From: Peter Korsgaard @ 2015-09-24 21:02 UTC (permalink / raw)
To: buildroot
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
Hi,
> It is my understanding that -mthumb will generate Thumb2 instructions on
> cores that have Thumb2 (e.g. Cortex), and Thumb (aka Thumb1) on cores
> that do not have Thumb2.
> Also, since Thumb2 is a strict superset of Thumb, then having Thumb2
> means having Thumb, at least from an instruction set point of view.
> I believe Thumb2 should select Thumb.
Yes, that sounds sensible.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 3/3] Adding support for uclibcpp library
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 7:02 ` Chris Wardman
2015-09-13 22:00 ` Thomas Petazzoni
2015-09-13 8:17 ` [Buildroot] [PATCH 1/3] Experimental addition of the newlib library Thomas Petazzoni
2015-09-15 20:41 ` Yann E. MORIN
3 siblings, 1 reply; 23+ messages in thread
From: Chris Wardman @ 2015-09-13 7:02 UTC (permalink / raw)
To: buildroot
uclibcpp is built as an alternative to the standard libstdc++ library
It provides the support for c++ with a smaller memory footprint.
Right now it depends on newlib, because it has only been tested against newlib
Signed-off-by: Chris Wardman <cjwfirmware@vxmdesign.com>
---
.../uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch | 63 ++++++++++++++++++++++
package/uclibcpp/Config.in | 9 ++++
package/uclibcpp/uclibcpp.config | 54 +++++++++++++++++++
package/uclibcpp/uclibcpp.mk | 28 ++++++++++
toolchain/Config.in | 1 +
5 files changed, 155 insertions(+)
create mode 100644 package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch
create mode 100644 package/uclibcpp/Config.in
create mode 100644 package/uclibcpp/uclibcpp.config
create mode 100644 package/uclibcpp/uclibcpp.mk
diff --git a/package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch b/package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch
new file mode 100644
index 0000000..851b87e
--- /dev/null
+++ b/package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch
@@ -0,0 +1,63 @@
+Minor fixes so uclibcpp compiles.
+
+I have no clude why they wrote the Unwind_Exception_Class variable that way, but that doesn't compile
+
+uclibcpp needs isspace which is not provided otherwise
+
+Signed-off-by: Chris Wardman <cjwfirmware@vxmdesign.com>
+
+
+diff -uNr uClibc++-0.2.4/include/unwind-cxx.h uc_new/include/unwind-cxx.h
+--- uClibc++-0.2.4/include/unwind-cxx.h 2012-05-25 17:15:31.000000000 -0400
++++ uc_new/include/unwind-cxx.h 2015-01-15 16:29:05.358633886 -0500
+@@ -172,15 +172,7 @@
+ // These are explicitly GNU C++ specific.
+
+ // This is the exception class we report -- "GNUCC++\0".
+-const _Unwind_Exception_Class __gxx_exception_class
+-= ((((((((_Unwind_Exception_Class) 'G'
+- << 8 | (_Unwind_Exception_Class) 'N')
+- << 8 | (_Unwind_Exception_Class) 'U')
+- << 8 | (_Unwind_Exception_Class) 'C')
+- << 8 | (_Unwind_Exception_Class) 'C')
+- << 8 | (_Unwind_Exception_Class) '+')
+- << 8 | (_Unwind_Exception_Class) '+')
+- << 8 | (_Unwind_Exception_Class) '\0');
++ const _Unwind_Exception_Class __gxx_exception_class = "GNUCC++";
+
+ // GNU C++ personality routine, Version 0.
+ extern "C" _Unwind_Reason_Code __gxx_personality_v0
+diff -uNr uClibc++-0.2.4/Rules.mak uc_new/Rules.mak
+--- uClibc++-0.2.4/Rules.mak 2012-05-25 17:15:31.000000000 -0400
++++ uc_new/Rules.mak 2015-01-15 16:29:05.358633886 -0500
+@@ -107,7 +107,7 @@
+
+ # Some nice CFLAGS to work with
+ GEN_CFLAGS:=-fno-builtin
+-CFLAGS:=$(XWARNINGS) $(CPU_CFLAGS) -ansi
++CFLAGS:=$(XWARNINGS) $(CPU_CFLAGS)
+
+ LDFLAGS:=-Wl,--warn-common -Wl,--warn-once -Wl,-z,combreloc -Wl,-z,defs
+
+diff -uNr uClibc++-0.2.4/src/_ct_chr.cpp uc_new/src/_ct_chr.cpp
+--- uClibc++-0.2.4/src/_ct_chr.cpp 1969-12-31 19:00:00.000000000 -0500
++++ uc_new/src/_ct_chr.cpp 2015-01-15 16:29:21.478634145 -0500
+@@ -0,0 +1,18 @@
++#include <_ansi.h>
++#include <ctype.h>
++
++int _DEFUN(isspace, (c),int c){
++ switch(c){
++ case ' ':
++ case '\r':
++ case '\n':
++ case '\b':
++ case '\t':
++ return true;
++ }
++ return false;
++}
++
++int _DEFUN(isdigit, (c), int c){
++ return ('0' <= c && c <= '9');
++}
diff --git a/package/uclibcpp/Config.in b/package/uclibcpp/Config.in
new file mode 100644
index 0000000..d0a962a
--- /dev/null
+++ b/package/uclibcpp/Config.in
@@ -0,0 +1,9 @@
+config BR2_PACKAGE_UCLIBCPP
+ bool "uClibc++ C++ library"
+ depends on BR2_TOOLCHAIN_BUILDROOT_NEWLIB
+ depends on BR2_TOOLCHAIN_BUILDROOT_CXX
+ help
+ Uclibc++ library support. Smaller than libvstdc++
+
+
+
diff --git a/package/uclibcpp/uclibcpp.config b/package/uclibcpp/uclibcpp.config
new file mode 100644
index 0000000..4e2d0ec
--- /dev/null
+++ b/package/uclibcpp/uclibcpp.config
@@ -0,0 +1,54 @@
+#
+# Automatically generated make config: don't edit
+#
+
+#
+# Target Features and Options
+#
+UCLIBCXX_HAS_FLOATS=y
+UCLIBCXX_HAS_LONG_DOUBLE=y
+UCLIBCXX_HAS_TLS=y
+WARNINGS="-Wall"
+BUILD_EXTRA_LIBRARIES=""
+HAVE_DOT_CONFIG=y
+
+#
+# String and I/O Stream Support
+#
+# UCLIBCXX_HAS_WCHAR is not set
+UCLIBCXX_IOSTREAM_BUFSIZE=32
+UCLIBCXX_HAS_LFS=y
+UCLIBCXX_SUPPORT_CDIR=y
+UCLIBCXX_SUPPORT_CIN=y
+UCLIBCXX_SUPPORT_COUT=y
+UCLIBCXX_SUPPORT_CERR=y
+# UCLIBCXX_SUPPORT_CLOG is not set
+
+#
+# STL and Code Expansion
+#
+UCLIBCXX_STL_BUFFER_SIZE=32
+UCLIBCXX_CODE_EXPANSION=y
+UCLIBCXX_EXPAND_CONSTRUCTORS_DESTRUCTORS=y
+UCLIBCXX_EXPAND_STRING_CHAR=y
+UCLIBCXX_EXPAND_VECTOR_BASIC=y
+UCLIBCXX_EXPAND_IOS_CHAR=y
+UCLIBCXX_EXPAND_STREAMBUF_CHAR=y
+UCLIBCXX_EXPAND_ISTREAM_CHAR=y
+UCLIBCXX_EXPAND_OSTREAM_CHAR=y
+UCLIBCXX_EXPAND_FSTREAM_CHAR=y
+UCLIBCXX_EXPAND_SSTREAM_CHAR=y
+
+#
+# Library Installation Options
+#
+UCLIBCXX_RUNTIME_PREFIX="/usr"
+UCLIBCXX_RUNTIME_INCLUDE_SUBDIR="/include"
+UCLIBCXX_RUNTIME_LIB_SUBDIR="/lib"
+UCLIBCXX_RUNTIME_BIN_SUBDIR="/bin"
+UCLIBCXX_EXCEPTION_SUPPORT=y
+IMPORT_LIBSUP=y
+# IMPORT_LIBGCC_EH is not set
+BUILD_STATIC_LIB=y
+BUILD_ONLY_STATIC_LIB=y
+# DODEBUG is not set
diff --git a/package/uclibcpp/uclibcpp.mk b/package/uclibcpp/uclibcpp.mk
new file mode 100644
index 0000000..dfe8ede
--- /dev/null
+++ b/package/uclibcpp/uclibcpp.mk
@@ -0,0 +1,28 @@
+UCLIBCPP_VERSION = 0.2.4
+UCLIBCPP_SOURCE = uClibc++-$(UCLIBCPP_VERSION).tar.bz2
+UCLIBCPP_LICENSE = LGPLv3
+UCLIBCPP_SITE = http://cxx.uclibc.org/src/
+
+UCLIBCPP_INSTALL_STAGING = YES
+
+UCLIBCPP_DEPENDENCIES = host-gcc-final
+
+UCLIBCPP_KCONFIG_FILE = $(TOPDIR)/package/uclibcpp/uclibcpp.config
+
+UCLIBCPP_MAKE_FLAGS = CROSS=$(TARGET_CROSS)
+
+define UCLIBCPP_BUILD_CMDS
+ $(MAKE) -C $(@D) $(UCLIBCPP_MAKE_FLAGS)
+endef
+
+define UCLIBCPP_INSTALL_STAGING_CMDS
+ $(MAKE) -C $(@D) PREFIX=$(STAGING_DIR) install
+endef
+
+define UCLIBCPP_INSTALL_TARGET_CMDS
+ $(MAKE) -C $(@D) PREFIX=$(TARGET_DIR) install
+endef
+
+$(eval $(kconfig-package))
+
+
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 88ebe8c..3904f44 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -60,5 +60,6 @@ endchoice
source "toolchain/toolchain-buildroot/Config.in"
source "toolchain/toolchain-external/Config.in"
source "toolchain/toolchain-common.in"
+source "package/uclibcpp/Config.in"
endmenu
--
1.9.1
^ permalink raw reply related [flat|nested] 23+ messages in thread* [Buildroot] [PATCH 3/3] Adding support for uclibcpp library
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
0 siblings, 1 reply; 23+ messages in thread
From: Thomas Petazzoni @ 2015-09-13 22:00 UTC (permalink / raw)
To: buildroot
Chris,
The commit title should probably be:
toolchain: add support for the uclibcpp library
On Sun, 13 Sep 2015 03:02:48 -0400, Chris Wardman wrote:
> uclibcpp is built as an alternative to the standard libstdc++ library
The question is how does it replace the libstdc++ provided by gcc? Does
it simply overwrite it? So you're building C++ support in gcc normally
and then overwrite the libstdc++ from gcc with uclibcpp ?
Also, how compatible is it with the C++ standard? I.e will people be
able to build arbitrary C++ libraries/applications with this smaller
C++ library, or is it limited to a certain subset of the C++ standard?
> diff --git a/package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch b/package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch
> new file mode 100644
> index 0000000..851b87e
> --- /dev/null
> +++ b/package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch
The patches shouldn't start with the package name, so a proper name is:
0001-minor-fixes.patch
However, I believe this patch is really mixing too many things. Can you
split this uclibcpp patch into smaller piece, each fixing one
particular problem?
Also, since we're supporting only one version of uclibcpp at a time,
there is no need to put the patch in a 0.2.4/ subdirectory of
package/uclibcpp/. Just put them directly in package/uclibcpp.
> +I have no clude why they wrote the Unwind_Exception_Class variable that way, but that doesn't compile
Please wrap the patch description to 80 columns, and don't use first
person wording.
> +diff -uNr uClibc++-0.2.4/src/_ct_chr.cpp uc_new/src/_ct_chr.cpp
> +--- uClibc++-0.2.4/src/_ct_chr.cpp 1969-12-31 19:00:00.000000000 -0500
> ++++ uc_new/src/_ct_chr.cpp 2015-01-15 16:29:21.478634145 -0500
> +@@ -0,0 +1,18 @@
> ++#include <_ansi.h>
> ++#include <ctype.h>
> ++
> ++int _DEFUN(isspace, (c),int c){
> ++ switch(c){
> ++ case ' ':
> ++ case '\r':
> ++ case '\n':
> ++ case '\b':
> ++ case '\t':
> ++ return true;
> ++ }
> ++ return false;
> ++}
> ++
> ++int _DEFUN(isdigit, (c), int c){
> ++ return ('0' <= c && c <= '9');
> ++}
newlib is not providing isspace() and isdigit() ?
> diff --git a/package/uclibcpp/Config.in b/package/uclibcpp/Config.in
> new file mode 100644
> index 0000000..d0a962a
> --- /dev/null
> +++ b/package/uclibcpp/Config.in
> @@ -0,0 +1,9 @@
> +config BR2_PACKAGE_UCLIBCPP
> + bool "uClibc++ C++ library"
> + depends on BR2_TOOLCHAIN_BUILDROOT_NEWLIB
> + depends on BR2_TOOLCHAIN_BUILDROOT_CXX
> + help
Please use tab for indentation.
> + Uclibc++ library support. Smaller than libvstdc++
And one tab + two spaces for the help text. Also, fix the typo in the
description (libvstdc++ -> libstdc++) and maybe extend the description
with more details (difference between the original libstdc++ and
uclibcpp one).
> +
> +
> +
Unneeded empty lines.
> diff --git a/package/uclibcpp/uclibcpp.config b/package/uclibcpp/uclibcpp.config
> new file mode 100644
> index 0000000..4e2d0ec
> --- /dev/null
> +++ b/package/uclibcpp/uclibcpp.config
> @@ -0,0 +1,54 @@
> +#
> +# Automatically generated make config: don't edit
> +#
> +
> +#
> +# Target Features and Options
> +#
> +UCLIBCXX_HAS_FLOATS=y
> +UCLIBCXX_HAS_LONG_DOUBLE=y
> +UCLIBCXX_HAS_TLS=y
> +WARNINGS="-Wall"
> +BUILD_EXTRA_LIBRARIES=""
> +HAVE_DOT_CONFIG=y
> +
> +#
> +# String and I/O Stream Support
> +#
> +# UCLIBCXX_HAS_WCHAR is not set
> +UCLIBCXX_IOSTREAM_BUFSIZE=32
> +UCLIBCXX_HAS_LFS=y
> +UCLIBCXX_SUPPORT_CDIR=y
> +UCLIBCXX_SUPPORT_CIN=y
> +UCLIBCXX_SUPPORT_COUT=y
> +UCLIBCXX_SUPPORT_CERR=y
> +# UCLIBCXX_SUPPORT_CLOG is not set
> +
> +#
> +# STL and Code Expansion
> +#
> +UCLIBCXX_STL_BUFFER_SIZE=32
> +UCLIBCXX_CODE_EXPANSION=y
> +UCLIBCXX_EXPAND_CONSTRUCTORS_DESTRUCTORS=y
> +UCLIBCXX_EXPAND_STRING_CHAR=y
> +UCLIBCXX_EXPAND_VECTOR_BASIC=y
> +UCLIBCXX_EXPAND_IOS_CHAR=y
> +UCLIBCXX_EXPAND_STREAMBUF_CHAR=y
> +UCLIBCXX_EXPAND_ISTREAM_CHAR=y
> +UCLIBCXX_EXPAND_OSTREAM_CHAR=y
> +UCLIBCXX_EXPAND_FSTREAM_CHAR=y
> +UCLIBCXX_EXPAND_SSTREAM_CHAR=y
> +
> +#
> +# Library Installation Options
> +#
> +UCLIBCXX_RUNTIME_PREFIX="/usr"
> +UCLIBCXX_RUNTIME_INCLUDE_SUBDIR="/include"
> +UCLIBCXX_RUNTIME_LIB_SUBDIR="/lib"
> +UCLIBCXX_RUNTIME_BIN_SUBDIR="/bin"
> +UCLIBCXX_EXCEPTION_SUPPORT=y
> +IMPORT_LIBSUP=y
> +# IMPORT_LIBGCC_EH is not set
> +BUILD_STATIC_LIB=y
> +BUILD_ONLY_STATIC_LIB=y
> +# DODEBUG is not set
> diff --git a/package/uclibcpp/uclibcpp.mk b/package/uclibcpp/uclibcpp.mk
> new file mode 100644
> index 0000000..dfe8ede
> --- /dev/null
> +++ b/package/uclibcpp/uclibcpp.mk
> @@ -0,0 +1,28 @@
Missing comment header. Also please add a hash file (see
http://buildroot.uclibc.org/downloads/manual/manual.html#adding-packages-hash).
Maybe I forgot to say that in my review of your newlib package, but
please do it there as well.
> +UCLIBCPP_VERSION = 0.2.4
> +UCLIBCPP_SOURCE = uClibc++-$(UCLIBCPP_VERSION).tar.bz2
The last version is from May 2012, like uClibc itself. Is it a dead
project like uClibc ? If so, then I'm a bit worried in packaging
something so fundamental as the standard C++ library if it isn't
maintained.
There has been a few commits since the last release, see
http://git.uclibc.org/uClibc++/log/. But it still doesn't seem to be
very active. According to the website, there is not even a mailing list
for it.
You could use the .tar.xz tarball instead of .tar.bz2.
> +UCLIBCPP_LICENSE = LGPLv3
Some quick inspection indicates LGPLv2.1+
> +UCLIBCPP_SITE = http://cxx.uclibc.org/src/
> +
> +UCLIBCPP_INSTALL_STAGING = YES
> +
> +UCLIBCPP_DEPENDENCIES = host-gcc-final
All target packages depend on "toolchain", which has host-gcc-final as
part of its dependencies. However maybe, what you need is to have this
uclibcpp package built *before* any other target package that uses C++,
no? If so, then toolchain/toolchain/toolchain.mk needs to be modified
to add uclibcpp as a dependency when it is enabled. And of course,
uclibcpp.mk should specify UCLIBCPP_ADD_TOOLCHAIN_DEPENDENCY = NO.
> +
> +UCLIBCPP_KCONFIG_FILE = $(TOPDIR)/package/uclibcpp/uclibcpp.config
$(TOPDIR)/ not needed.
> +
> +UCLIBCPP_MAKE_FLAGS = CROSS=$(TARGET_CROSS)
> +
> +define UCLIBCPP_BUILD_CMDS
> + $(MAKE) -C $(@D) $(UCLIBCPP_MAKE_FLAGS)
> +endef
> +
> +define UCLIBCPP_INSTALL_STAGING_CMDS
> + $(MAKE) -C $(@D) PREFIX=$(STAGING_DIR) install
> +endef
> +
> +define UCLIBCPP_INSTALL_TARGET_CMDS
> + $(MAKE) -C $(@D) PREFIX=$(TARGET_DIR) install
> +endef
> +
> +$(eval $(kconfig-package))
> +
> +
Unneeded empty lines at the end of the file.
> diff --git a/toolchain/Config.in b/toolchain/Config.in
> index 88ebe8c..3904f44 100644
> --- a/toolchain/Config.in
> +++ b/toolchain/Config.in
> @@ -60,5 +60,6 @@ endchoice
> source "toolchain/toolchain-buildroot/Config.in"
> source "toolchain/toolchain-external/Config.in"
> source "toolchain/toolchain-common.in"
> +source "package/uclibcpp/Config.in"
This should go in toolchain/toolchain-buildroot/Config.in.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread* [Buildroot] [PATCH 3/3] Adding support for uclibcpp library
2015-09-13 22:00 ` Thomas Petazzoni
@ 2015-09-17 7:07 ` Cjw X
2015-09-17 7:25 ` Thomas Petazzoni
0 siblings, 1 reply; 23+ messages in thread
From: Cjw X @ 2015-09-17 7:07 UTC (permalink / raw)
To: buildroot
Hi Thomas, all,
(Sorry for the second email Thomas, didn't send the list)
You have some very valid concerns. For extremely small footprint
devices that want to use C++ I think this package will be useful, but
for now I'm not even using C++ in my embedded projects, so it is not
critical.
I don't think it is being maintained and it has some other issues, so,
I am going to leave this patch out for now.
Thanks!
-Chris
On Sun, Sep 13, 2015 at 6:00 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Chris,
>
> The commit title should probably be:
>
> toolchain: add support for the uclibcpp library
>
> On Sun, 13 Sep 2015 03:02:48 -0400, Chris Wardman wrote:
>> uclibcpp is built as an alternative to the standard libstdc++ library
>
> The question is how does it replace the libstdc++ provided by gcc? Does
> it simply overwrite it? So you're building C++ support in gcc normally
> and then overwrite the libstdc++ from gcc with uclibcpp ?
>
> Also, how compatible is it with the C++ standard? I.e will people be
> able to build arbitrary C++ libraries/applications with this smaller
> C++ library, or is it limited to a certain subset of the C++ standard?
>
>> diff --git a/package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch b/package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch
>> new file mode 100644
>> index 0000000..851b87e
>> --- /dev/null
>> +++ b/package/uclibcpp/0.2.4/uclibcpp-0001-minor-fixes.patch
>
> The patches shouldn't start with the package name, so a proper name is:
>
> 0001-minor-fixes.patch
>
> However, I believe this patch is really mixing too many things. Can you
> split this uclibcpp patch into smaller piece, each fixing one
> particular problem?
>
> Also, since we're supporting only one version of uclibcpp at a time,
> there is no need to put the patch in a 0.2.4/ subdirectory of
> package/uclibcpp/. Just put them directly in package/uclibcpp.
>
>> +I have no clude why they wrote the Unwind_Exception_Class variable that way, but that doesn't compile
>
> Please wrap the patch description to 80 columns, and don't use first
> person wording.
>
>> +diff -uNr uClibc++-0.2.4/src/_ct_chr.cpp uc_new/src/_ct_chr.cpp
>> +--- uClibc++-0.2.4/src/_ct_chr.cpp 1969-12-31 19:00:00.000000000 -0500
>> ++++ uc_new/src/_ct_chr.cpp 2015-01-15 16:29:21.478634145 -0500
>> +@@ -0,0 +1,18 @@
>> ++#include <_ansi.h>
>> ++#include <ctype.h>
>> ++
>> ++int _DEFUN(isspace, (c),int c){
>> ++ switch(c){
>> ++ case ' ':
>> ++ case '\r':
>> ++ case '\n':
>> ++ case '\b':
>> ++ case '\t':
>> ++ return true;
>> ++ }
>> ++ return false;
>> ++}
>> ++
>> ++int _DEFUN(isdigit, (c), int c){
>> ++ return ('0' <= c && c <= '9');
>> ++}
>
> newlib is not providing isspace() and isdigit() ?
>
>> diff --git a/package/uclibcpp/Config.in b/package/uclibcpp/Config.in
>> new file mode 100644
>> index 0000000..d0a962a
>> --- /dev/null
>> +++ b/package/uclibcpp/Config.in
>> @@ -0,0 +1,9 @@
>> +config BR2_PACKAGE_UCLIBCPP
>> + bool "uClibc++ C++ library"
>> + depends on BR2_TOOLCHAIN_BUILDROOT_NEWLIB
>> + depends on BR2_TOOLCHAIN_BUILDROOT_CXX
>> + help
>
> Please use tab for indentation.
>
>> + Uclibc++ library support. Smaller than libvstdc++
>
> And one tab + two spaces for the help text. Also, fix the typo in the
> description (libvstdc++ -> libstdc++) and maybe extend the description
> with more details (difference between the original libstdc++ and
> uclibcpp one).
>
>> +
>> +
>> +
>
> Unneeded empty lines.
>
>> diff --git a/package/uclibcpp/uclibcpp.config b/package/uclibcpp/uclibcpp.config
>> new file mode 100644
>> index 0000000..4e2d0ec
>> --- /dev/null
>> +++ b/package/uclibcpp/uclibcpp.config
>> @@ -0,0 +1,54 @@
>> +#
>> +# Automatically generated make config: don't edit
>> +#
>> +
>> +#
>> +# Target Features and Options
>> +#
>> +UCLIBCXX_HAS_FLOATS=y
>> +UCLIBCXX_HAS_LONG_DOUBLE=y
>> +UCLIBCXX_HAS_TLS=y
>> +WARNINGS="-Wall"
>> +BUILD_EXTRA_LIBRARIES=""
>> +HAVE_DOT_CONFIG=y
>> +
>> +#
>> +# String and I/O Stream Support
>> +#
>> +# UCLIBCXX_HAS_WCHAR is not set
>> +UCLIBCXX_IOSTREAM_BUFSIZE=32
>> +UCLIBCXX_HAS_LFS=y
>> +UCLIBCXX_SUPPORT_CDIR=y
>> +UCLIBCXX_SUPPORT_CIN=y
>> +UCLIBCXX_SUPPORT_COUT=y
>> +UCLIBCXX_SUPPORT_CERR=y
>> +# UCLIBCXX_SUPPORT_CLOG is not set
>> +
>> +#
>> +# STL and Code Expansion
>> +#
>> +UCLIBCXX_STL_BUFFER_SIZE=32
>> +UCLIBCXX_CODE_EXPANSION=y
>> +UCLIBCXX_EXPAND_CONSTRUCTORS_DESTRUCTORS=y
>> +UCLIBCXX_EXPAND_STRING_CHAR=y
>> +UCLIBCXX_EXPAND_VECTOR_BASIC=y
>> +UCLIBCXX_EXPAND_IOS_CHAR=y
>> +UCLIBCXX_EXPAND_STREAMBUF_CHAR=y
>> +UCLIBCXX_EXPAND_ISTREAM_CHAR=y
>> +UCLIBCXX_EXPAND_OSTREAM_CHAR=y
>> +UCLIBCXX_EXPAND_FSTREAM_CHAR=y
>> +UCLIBCXX_EXPAND_SSTREAM_CHAR=y
>> +
>> +#
>> +# Library Installation Options
>> +#
>> +UCLIBCXX_RUNTIME_PREFIX="/usr"
>> +UCLIBCXX_RUNTIME_INCLUDE_SUBDIR="/include"
>> +UCLIBCXX_RUNTIME_LIB_SUBDIR="/lib"
>> +UCLIBCXX_RUNTIME_BIN_SUBDIR="/bin"
>> +UCLIBCXX_EXCEPTION_SUPPORT=y
>> +IMPORT_LIBSUP=y
>> +# IMPORT_LIBGCC_EH is not set
>> +BUILD_STATIC_LIB=y
>> +BUILD_ONLY_STATIC_LIB=y
>> +# DODEBUG is not set
>> diff --git a/package/uclibcpp/uclibcpp.mk b/package/uclibcpp/uclibcpp.mk
>> new file mode 100644
>> index 0000000..dfe8ede
>> --- /dev/null
>> +++ b/package/uclibcpp/uclibcpp.mk
>> @@ -0,0 +1,28 @@
>
> Missing comment header. Also please add a hash file (see
> http://buildroot.uclibc.org/downloads/manual/manual.html#adding-packages-hash).
> Maybe I forgot to say that in my review of your newlib package, but
> please do it there as well.
>
>> +UCLIBCPP_VERSION = 0.2.4
>> +UCLIBCPP_SOURCE = uClibc++-$(UCLIBCPP_VERSION).tar.bz2
>
> The last version is from May 2012, like uClibc itself. Is it a dead
> project like uClibc ? If so, then I'm a bit worried in packaging
> something so fundamental as the standard C++ library if it isn't
> maintained.
>
> There has been a few commits since the last release, see
> http://git.uclibc.org/uClibc++/log/. But it still doesn't seem to be
> very active. According to the website, there is not even a mailing list
> for it.
>
> You could use the .tar.xz tarball instead of .tar.bz2.
>
>> +UCLIBCPP_LICENSE = LGPLv3
>
> Some quick inspection indicates LGPLv2.1+
>
>> +UCLIBCPP_SITE = http://cxx.uclibc.org/src/
>> +
>> +UCLIBCPP_INSTALL_STAGING = YES
>> +
>> +UCLIBCPP_DEPENDENCIES = host-gcc-final
>
> All target packages depend on "toolchain", which has host-gcc-final as
> part of its dependencies. However maybe, what you need is to have this
> uclibcpp package built *before* any other target package that uses C++,
> no? If so, then toolchain/toolchain/toolchain.mk needs to be modified
> to add uclibcpp as a dependency when it is enabled. And of course,
> uclibcpp.mk should specify UCLIBCPP_ADD_TOOLCHAIN_DEPENDENCY = NO.
>
>> +
>> +UCLIBCPP_KCONFIG_FILE = $(TOPDIR)/package/uclibcpp/uclibcpp.config
>
> $(TOPDIR)/ not needed.
>
>> +
>> +UCLIBCPP_MAKE_FLAGS = CROSS=$(TARGET_CROSS)
>> +
>> +define UCLIBCPP_BUILD_CMDS
>> + $(MAKE) -C $(@D) $(UCLIBCPP_MAKE_FLAGS)
>> +endef
>> +
>> +define UCLIBCPP_INSTALL_STAGING_CMDS
>> + $(MAKE) -C $(@D) PREFIX=$(STAGING_DIR) install
>> +endef
>> +
>> +define UCLIBCPP_INSTALL_TARGET_CMDS
>> + $(MAKE) -C $(@D) PREFIX=$(TARGET_DIR) install
>> +endef
>> +
>> +$(eval $(kconfig-package))
>> +
>> +
>
> Unneeded empty lines at the end of the file.
>
>> diff --git a/toolchain/Config.in b/toolchain/Config.in
>> index 88ebe8c..3904f44 100644
>> --- a/toolchain/Config.in
>> +++ b/toolchain/Config.in
>> @@ -60,5 +60,6 @@ endchoice
>> source "toolchain/toolchain-buildroot/Config.in"
>> source "toolchain/toolchain-external/Config.in"
>> source "toolchain/toolchain-common.in"
>> +source "package/uclibcpp/Config.in"
>
> This should go in toolchain/toolchain-buildroot/Config.in.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread* [Buildroot] [PATCH 3/3] Adding support for uclibcpp library
2015-09-17 7:07 ` Cjw X
@ 2015-09-17 7:25 ` Thomas Petazzoni
0 siblings, 0 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2015-09-17 7:25 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Sep 2015 03:07:46 -0400, Cjw X wrote:
> You have some very valid concerns. For extremely small footprint
> devices that want to use C++ I think this package will be useful, but
> for now I'm not even using C++ in my embedded projects, so it is not
> critical.
>
> I don't think it is being maintained and it has some other issues, so,
> I am going to leave this patch out for now.
Ok, thanks for the explanation. It's indeed better if we can leave this
on the side, at least for now.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
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 7:02 ` [Buildroot] [PATCH 3/3] Adding support for uclibcpp library Chris Wardman
@ 2015-09-13 8:17 ` Thomas Petazzoni
2015-09-15 4:06 ` Cjw X
` (2 more replies)
2015-09-15 20:41 ` Yann E. MORIN
3 siblings, 3 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2015-09-13 8:17 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
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
2015-09-15 20:45 ` Yann E. MORIN
2015-09-16 17:36 ` Cjw X
2 siblings, 1 reply; 23+ messages in thread
From: Cjw X @ 2015-09-15 4:06 UTC (permalink / raw)
To: buildroot
So, I'm going through comments and investigating. Everything seems
pretty reasonable.
I'll have more comments and an updated patch soon. First though, for
the vendor in the toolchain...
On Sun, Sep 13, 2015 at 4:17 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> 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?
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.
If anyone has some suggestions about what I'm doing wrong there, I'd
love to know.
Thanks,
-Chris
>
>> 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
2015-09-15 4:06 ` Cjw X
@ 2015-09-15 7:35 ` Thomas Petazzoni
2015-09-15 17:53 ` Yann E. MORIN
0 siblings, 1 reply; 23+ messages in thread
From: Thomas Petazzoni @ 2015-09-15 7:35 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
2015-09-15 7:35 ` Thomas Petazzoni
@ 2015-09-15 17:53 ` Yann E. MORIN
2015-09-15 19:39 ` Thomas Petazzoni
0 siblings, 1 reply; 23+ messages in thread
From: Yann E. MORIN @ 2015-09-15 17:53 UTC (permalink / raw)
To: buildroot
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. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 23+ messages in thread* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
2015-09-15 17:53 ` Yann E. MORIN
@ 2015-09-15 19:39 ` Thomas Petazzoni
2015-09-24 21:30 ` Peter Korsgaard
0 siblings, 1 reply; 23+ messages in thread
From: Thomas Petazzoni @ 2015-09-15 19:39 UTC (permalink / raw)
To: buildroot
Yann, Peter, Chris,
On Tue, 15 Sep 2015 19:53:54 +0200, Yann E. MORIN wrote:
> > 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.
Thanks a lot for this explanation! It makes a lot more sense now. So,
Chris, I guess you have to rework your patch set in this direction:
it's not the vendor part of the tuple that is omitted.
> 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...
Chris is the person who submitted the support for the NuttX operating
system, which is another operating system kernel than Linux. In this
context, newlib is the C library of choice.
Now, there is indeed the question of how to handle all the existing
packages that would anyway only build with a normal Linux C library.
It's an open debate.
Maybe we first need to get an agreement on whether we want to merge
something such a newlib toolchain support and NuttX support. On my
side, I believe I am quite favorable to that, but I was also favorable
to Luca's patch series on the mdev stuff without devtmpfs, which is why
Luca started working on this, but in the end, it got turned down. So
this time around, it would be better if Peter could have a look at the
original patch from Chris (which definitely wasn't mergeable as is, but
was giving an idea of what was needed), and give his opinion on whether
we want something like this in Buildroot or not.
My view is that Buildroot is probably easier to use than Crosstool-NG,
even to build a simple bare-metal toolchain. Crosstool-NG has too many
options, and too many combinations that fail to build. There is a
discussion on-going on the crossgcc@ mailing list about that, but I can
see the interest in having a simpler to use tool to build bare-metal
toolchains.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
2015-09-15 19:39 ` Thomas Petazzoni
@ 2015-09-24 21:30 ` Peter Korsgaard
2015-09-25 7:30 ` Thomas Petazzoni
0 siblings, 1 reply; 23+ messages in thread
From: Peter Korsgaard @ 2015-09-24 21:30 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
Sorry for the slow response, I've been away and busy with deadlines at
$WORK.
>> 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...
> Chris is the person who submitted the support for the NuttX operating
> system, which is another operating system kernel than Linux. In this
> context, newlib is the C library of choice.
> Now, there is indeed the question of how to handle all the existing
> packages that would anyway only build with a normal Linux C library.
> It's an open debate.
> Maybe we first need to get an agreement on whether we want to merge
> something such a newlib toolchain support and NuttX support. On my
> side, I believe I am quite favorable to that, but I was also favorable
> to Luca's patch series on the mdev stuff without devtmpfs, which is why
> Luca started working on this, but in the end, it got turned down.
I wouldn't call it "getting turned down", I simply wanted to make it
clear that just working around old kernels in mdev wouldn't fix the
various other packages that haven't ever been tested on such ancient
kernels, and for the mdev issue a simpler fix would just be to backport
devtmpfs support to the kernel.
I must say that my initial thought when seeing the newlib patches was
that this was really outside the scope of Buildroot, but the patches ARE
quite small and self contained, so if there is interest it might make
sense after all.
I does require that we basically stick the entire package/ under an
ifndef NEWLIB (and system / fs / linux as well), and it will stay a
lower priority than the normal Linux stuff, but if that can be done
at a high enough level then that is probably ok.
I recently bought one of those cheap arduino clones with a stm32f103
(m3) for tinkering, so I might even use it myself! ;)
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
2015-09-24 21:30 ` Peter Korsgaard
@ 2015-09-25 7:30 ` Thomas Petazzoni
2015-09-27 16:40 ` Cjw X
0 siblings, 1 reply; 23+ messages in thread
From: Thomas Petazzoni @ 2015-09-25 7:30 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 24 Sep 2015 23:30:33 +0200, Peter Korsgaard wrote:
> > Maybe we first need to get an agreement on whether we want to merge
> > something such a newlib toolchain support and NuttX support. On my
> > side, I believe I am quite favorable to that, but I was also favorable
> > to Luca's patch series on the mdev stuff without devtmpfs, which is why
> > Luca started working on this, but in the end, it got turned down.
>
> I wouldn't call it "getting turned down", I simply wanted to make it
> clear that just working around old kernels in mdev wouldn't fix the
> various other packages that haven't ever been tested on such ancient
> kernels, and for the mdev issue a simpler fix would just be to backport
> devtmpfs support to the kernel.
>
> I must say that my initial thought when seeing the newlib patches was
> that this was really outside the scope of Buildroot, but the patches ARE
> quite small and self contained, so if there is interest it might make
> sense after all.
>
> I does require that we basically stick the entire package/ under an
> ifndef NEWLIB (and system / fs / linux as well), and it will stay a
> lower priority than the normal Linux stuff, but if that can be done
> at a high enough level then that is probably ok.
>
> I recently bought one of those cheap arduino clones with a stm32f103
> (m3) for tinkering, so I might even use it myself! ;)
Great, thanks for the feedback. Then we'll continue to work with Chris
to provide a proper solution.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
2015-09-25 7:30 ` Thomas Petazzoni
@ 2015-09-27 16:40 ` Cjw X
0 siblings, 0 replies; 23+ messages in thread
From: Cjw X @ 2015-09-27 16:40 UTC (permalink / raw)
To: buildroot
Hi All, Thomas,
On Fri, Sep 25, 2015 at 3:30 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Thu, 24 Sep 2015 23:30:33 +0200, Peter Korsgaard wrote:
>
>> > Maybe we first need to get an agreement on whether we want to merge
>> > something such a newlib toolchain support and NuttX support. On my
>> > side, I believe I am quite favorable to that, but I was also favorable
>> > to Luca's patch series on the mdev stuff without devtmpfs, which is why
>> > Luca started working on this, but in the end, it got turned down.
>>
>> I wouldn't call it "getting turned down", I simply wanted to make it
>> clear that just working around old kernels in mdev wouldn't fix the
>> various other packages that haven't ever been tested on such ancient
>> kernels, and for the mdev issue a simpler fix would just be to backport
>> devtmpfs support to the kernel.
>>
>> I must say that my initial thought when seeing the newlib patches was
>> that this was really outside the scope of Buildroot, but the patches ARE
>> quite small and self contained, so if there is interest it might make
>> sense after all.
>>
>> I does require that we basically stick the entire package/ under an
>> ifndef NEWLIB (and system / fs / linux as well), and it will stay a
>> lower priority than the normal Linux stuff, but if that can be done
>> at a high enough level then that is probably ok.
>>
>> I recently bought one of those cheap arduino clones with a stm32f103
>> (m3) for tinkering, so I might even use it myself! ;)
>
> Great, thanks for the feedback. Then we'll continue to work with Chris
> to provide a proper solution.
>
That is great news!
I submitted a few patches a few days ago. How do those look? I'm
guessing that is much closer to what you want.
Thanks,
-Chris
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
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 20:45 ` Yann E. MORIN
[not found] ` <CAOudHSVLKiTwrkv0xBNVW=ry3w1yOv4TJqP8+JMFSJRzw3dASQ@mail.gmail.com>
2015-09-16 17:36 ` Cjw X
2 siblings, 1 reply; 23+ messages in thread
From: Yann E. MORIN @ 2015-09-15 20:45 UTC (permalink / raw)
To: buildroot
Thomas, Cris, All,
On 2015-09-13 10:17 +0200, Thomas Petazzoni spake thusly:
>
> 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
[--SNIP--]
> > 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
> > +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.
Because newlib does not interpret --build, --host and --target like the
other autotools-based packages do. newlib basically ignores --build,
considers --host as the buld machine, and --target as the host. :-/
[--SNIP--]
> > +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.
In which case a pre-install hook can be used to do the mkdir.
But it would probably not be needed if $(GNU_TARGET_NAME) is a symlink
to "." .
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. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 23+ messages in thread* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
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 20:45 ` Yann E. MORIN
@ 2015-09-16 17:36 ` Cjw X
2015-09-16 17:38 ` Thomas Petazzoni
2 siblings, 1 reply; 23+ messages in thread
From: Cjw X @ 2015-09-16 17:36 UTC (permalink / raw)
To: buildroot
Hi Thomas,
I've gotten newlib moved over to the autotools infrastructure. I
should be able to post updated patches tonight.
>
>> +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.
So, that mkdir command needs to be run, and the it is most closely
associated with the staging install.
Is there some way to run mkdir then without overriding the
install_staging define? I haven't found anything in the docs.
Thanks,
-Chris
>
> Thanks a lot!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
2015-09-16 17:36 ` Cjw X
@ 2015-09-16 17:38 ` Thomas Petazzoni
0 siblings, 0 replies; 23+ messages in thread
From: Thomas Petazzoni @ 2015-09-16 17:38 UTC (permalink / raw)
To: buildroot
Hello Chris,
On Wed, 16 Sep 2015 13:36:20 -0400, Cjw X wrote:
> I've gotten newlib moved over to the autotools infrastructure. I
> should be able to post updated patches tonight.
Good. However, don't hold your breath. While I think adding newlib
support is interesting in Buildroot, it may not be the opinion of
others.
> > Except the mkdir, the install command is not needed if you use the
> > autotools-package infrastructure.
>
> So, that mkdir command needs to be run, and the it is most closely
> associated with the staging install.
> Is there some way to run mkdir then without overriding the
> install_staging define? I haven't found anything in the docs.
Search for <pkg>_PRE_INSTALL_STAGING_HOOKS in the documentation, and
generally the concept of hooks. See
http://buildroot.org/downloads/manual/manual.html#hooks.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
2015-09-13 7:02 [Buildroot] [PATCH 1/3] Experimental addition of the newlib library Chris Wardman
` (2 preceding siblings ...)
2015-09-13 8:17 ` [Buildroot] [PATCH 1/3] Experimental addition of the newlib library Thomas Petazzoni
@ 2015-09-15 20:41 ` Yann E. MORIN
2015-09-17 7:41 ` Cjw X
3 siblings, 1 reply; 23+ messages in thread
From: Yann E. MORIN @ 2015-09-15 20:41 UTC (permalink / raw)
To: buildroot
Chris, All,
On 2015-09-13 03:02 -0400, Chris Wardman spake thusly:
> 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
OK, I eventually had a bit of time to gave a cusory glance at the
patch...
> Signed-off-by: Chris Wardman <cjwfirmware@vxmdesign.com>
[--SNIP--]
> 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)
> +else
> GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(TARGET_OS)-$(LIBC)$(ABI)
> +endif
>
> # FLAT binary format needs uclinux
> -ifeq ($(BR2_BINFMT_FLAT),y)
> +ifeq ($(BR2_TOOLCHAIN_USES_NEWLIB),y)
> +TARGET_OS = none
See how you have to set TARGET_OS=none here? With the change above we've
been discussing previously, this would construct a three-part tuple as
(because LIBC is empty, too, below):
$(ARCH)-none-$(ABI)
which is directly in line with what I previosuly explained. Yeah me! :-)
> +else ifeq ($(BR2_BINFMT_FLAT),y)
> TARGET_OS = uclinux
> else
> TARGET_OS = linux
> @@ -50,6 +56,8 @@ ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
> LIBC = uclibc
> else ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> LIBC = musl
> +else ifeq ($(BR2_TOOLCHAIN_USES_NEWLIB),y)
> +LIBC =
... here.
> else
> LIBC = gnu
> endif
> diff --git a/package/gcc/gcc-final/gcc-final.mk b/package/gcc/gcc-final/gcc-final.mk
I haven't had a look at the gcc part yet...
[--SNIP--]
> 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
Wouldn't that be the case for creating the symlink arm-none-eabi -> . as
we're doing for some external toolchains?
> +${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}
But the patch looks pretty clean...
> + # Create a .gdbinit file which runs the one in srcdir
> 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
> +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) \
From what I recall, newlib does not use --build. So you should not have
to specify it. At l;east, it was still the case in newlib-2.2.0,
released 2014-12-18.
> + --prefix=$(STAGING_DIR) \
> + --includedir=$(STAGING_DIR)/usr/include \
> + --oldincludedir=$(STAGING_DIR)/usr/include \
> + --with-build-sysroot=$(STAGING_DIR) \
I don't think --includedir, --oldincludedir or --with-build-sysroot are
needed.
> + --enable-newlib-io-long-long \
> + --enable-newlib-register-fini \
> + --disable-newlib-supplied-syscalls \
What about --enable-newlib-io-float or --enable-newlib-io-long-double or
--enable-newlib-io-c99-formats?
(I don't really care they be enabled or disabled, just I would not use
the defaults; we prefer to force these kind of things explcitly, rather
than have nasty surprises, especially when a new version changes the
defaults, and especially since a toolchain component is pretty much
critical.)
> + --disable-nls)
> +
> +endef
> +
> +define NEWLIB_APPLY_PATCHES
> + $(APPLY_PATCHES) $(@D) package/newlib \*.patch
> +endef
> +
> +define NEWLIB_BUILD_CMDS
> + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)
> +endef
> +
> +define NEWLIB_INSTALL_STAGING_CMDS
> + mkdir -p $(HOST_DIR)/usr/$(GNU_TARGET_NAME)/lib
> + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) install
> +endef
> +
> +$(eval $(generic-package))
Maybe you can make that an autootols package, since it *is* an autotools
package. It's just that we're redefining the configure command.
But you're also not providing target-install commands, so you may also
want to add:
NEWLIB_INSTALL_TARGET = NO
And then you can indeed make it an autootls-package. :-)
> diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
> index 13e2b15..c11db73 100644
> --- a/toolchain/toolchain-buildroot/Config.in
> +++ b/toolchain/toolchain-buildroot/Config.in
> @@ -94,6 +94,14 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL
> This option selects musl as the C library for the
> cross-compilation toolchain.
>
> +config BR2_TOOLCHAIN_BUILDROOT_NEWLIB
> + bool "newlib (experimental)"
> + depends on BR2_arm
Why only arm? newlib has support for other architectures. In fact, I
would gues that all architectures that Buildroot supports are also
supported in newlib.
Note: for glibc and uClibc, we have a choice to select the version. Do
we also want to add such a version selection (especially a custom
version) for newlib, too?
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. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 23+ messages in thread* [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
2015-09-15 20:41 ` Yann E. MORIN
@ 2015-09-17 7:41 ` Cjw X
0 siblings, 0 replies; 23+ messages in thread
From: Cjw X @ 2015-09-17 7:41 UTC (permalink / raw)
To: buildroot
Hi Yann, all,
I just sent out a patch that I think addresses the reviews given.
Some minor comments below.
On Tue, Sep 15, 2015 at 4:41 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Chris, All,
>
> On 2015-09-13 03:02 -0400, Chris Wardman spake thusly:
>> 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
>
> OK, I eventually had a bit of time to gave a cusory glance at the
> patch...
>
>> Signed-off-by: Chris Wardman <cjwfirmware@vxmdesign.com>
> [--SNIP--]
>> 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)
>> +else
>> GNU_TARGET_NAME = $(ARCH)-$(TARGET_VENDOR)-$(TARGET_OS)-$(LIBC)$(ABI)
>> +endif
>>
>> # FLAT binary format needs uclinux
>> -ifeq ($(BR2_BINFMT_FLAT),y)
>> +ifeq ($(BR2_TOOLCHAIN_USES_NEWLIB),y)
>> +TARGET_OS = none
>
> See how you have to set TARGET_OS=none here? With the change above we've
> been discussing previously, this would construct a three-part tuple as
> (because LIBC is empty, too, below):
> $(ARCH)-none-$(ABI)
>
> which is directly in line with what I previosuly explained. Yeah me! :-)
>
>> +else ifeq ($(BR2_BINFMT_FLAT),y)
>> TARGET_OS = uclinux
>> else
>> TARGET_OS = linux
>> @@ -50,6 +56,8 @@ ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
>> LIBC = uclibc
>> else ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
>> LIBC = musl
>> +else ifeq ($(BR2_TOOLCHAIN_USES_NEWLIB),y)
>> +LIBC =
>
> ... here.
>
>> else
>> LIBC = gnu
>> endif
>> diff --git a/package/gcc/gcc-final/gcc-final.mk b/package/gcc/gcc-final/gcc-final.mk
>
> I haven't had a look at the gcc part yet...
>
> [--SNIP--]
>> 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
>
> Wouldn't that be the case for creating the symlink arm-none-eabi -> . as
> we're doing for some external toolchains?
>
>> +${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}
>
> But the patch looks pretty clean...
>
>> + # Create a .gdbinit file which runs the one in srcdir
>> 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
>> +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) \
>
> From what I recall, newlib does not use --build. So you should not have
> to specify it. At l;east, it was still the case in newlib-2.2.0,
> released 2014-12-18.
>
>> + --prefix=$(STAGING_DIR) \
>> + --includedir=$(STAGING_DIR)/usr/include \
>> + --oldincludedir=$(STAGING_DIR)/usr/include \
>> + --with-build-sysroot=$(STAGING_DIR) \
>
> I don't think --includedir, --oldincludedir or --with-build-sysroot are
> needed.
>
>> + --enable-newlib-io-long-long \
>> + --enable-newlib-register-fini \
>> + --disable-newlib-supplied-syscalls \
>
> What about --enable-newlib-io-float or --enable-newlib-io-long-double or
> --enable-newlib-io-c99-formats?
>
> (I don't really care they be enabled or disabled, just I would not use
> the defaults; we prefer to force these kind of things explcitly, rather
> than have nasty surprises, especially when a new version changes the
> defaults, and especially since a toolchain component is pretty much
> critical.)
>
I never went through the flag options in detail. I took the options
from a 'known good' build of the toolchain which was designed to run
with this target.
At one point I did try to go through the options in detail, but found
that I did not get the results I expected.
If we decide to include newlib in the buildroot, I think it would be
very valuable to figure out the different options and potentially add
config options to select them (or make them dependent on other
selections).
I think it would also be valuable to provide the option to use
specific versions newlib.
Thanks!
-Chris
>> + --disable-nls)
>> +
>> +endef
>> +
>> +define NEWLIB_APPLY_PATCHES
>> + $(APPLY_PATCHES) $(@D) package/newlib \*.patch
>> +endef
>> +
>> +define NEWLIB_BUILD_CMDS
>> + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)
>> +endef
>> +
>> +define NEWLIB_INSTALL_STAGING_CMDS
>> + mkdir -p $(HOST_DIR)/usr/$(GNU_TARGET_NAME)/lib
>> + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) install
>> +endef
>> +
>> +$(eval $(generic-package))
>
> Maybe you can make that an autootols package, since it *is* an autotools
> package. It's just that we're redefining the configure command.
>
> But you're also not providing target-install commands, so you may also
> want to add:
>
> NEWLIB_INSTALL_TARGET = NO
>
> And then you can indeed make it an autootls-package. :-)
>
>> diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
>> index 13e2b15..c11db73 100644
>> --- a/toolchain/toolchain-buildroot/Config.in
>> +++ b/toolchain/toolchain-buildroot/Config.in
>> @@ -94,6 +94,14 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL
>> This option selects musl as the C library for the
>> cross-compilation toolchain.
>>
>> +config BR2_TOOLCHAIN_BUILDROOT_NEWLIB
>> + bool "newlib (experimental)"
>> + depends on BR2_arm
>
> Why only arm? newlib has support for other architectures. In fact, I
> would gues that all architectures that Buildroot supports are also
> supported in newlib.
>
> Note: for glibc and uClibc, we have a choice to select the version. Do
> we also want to add such a version selection (especially a custom
> version) for newlib, too?
>
> 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. |
> '------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 23+ messages in thread