There is a variation of Newlib called newlib-nano which is optimized for smaller systems. The ARM-supported gcc-arm-embedded toolchain in Ubuntu distributes two versions of the library, newlib as regular libc.a, libg.a etc. and newlib-nano as libc_nano.a, libg_nano.a etc. Some embedded projects use these *_nano.a libs for linking and it would be useful to be able to provide the same kind of libraries in Gentoo. I have attached an ebuild with an added USE flag 'newlib-nano' which enables the Debian/Ubuntu behaviour of building newlib twice, first normally, then as "nano". The files for the nano version are installed to the same names as in the deb packages, (that is, with the suffix _nano) I have tested the ebuild on the live newlib-9999, did not try 2.1.0 or any earlier version. According to some posts around the Ubuntu gcc-arm-embedded project the nano functions were only recently upstreamed, before this it was living as a separate fork. For more information: http://community.arm.com/groups/embedded/blog/2013/01/21/shrink-your-mcu-code-size-with-gcc-arm-embedded-47 https://answers.launchpad.net/gcc-arm-embedded/+question/244125 Reproducible: Always
Created attachment 391522 [details] newlib-9999.ebuild The behaviour of the ebuild is based on the Debian script at https://tracker.debian.org/media/packages/n/newlib/rules-2.1.0%2Bgit20140818.1a8323b-2
Comment on attachment 391522 [details] newlib-9999.ebuild please post diffs, not full files
Created attachment 423336 [details, diff] newlib-nano.patch Patch against recent ebuild to add newlib-nano support.
Created attachment 423652 [details, diff] newlib-nano-r1.patch Added CFLAGS and CCASFLAGS handling to add -Os to the nano build and -ffunction-sections -fdata-sections to all builds. The CCASFLAGS -Os flag (set/not set) must match CFLAGS -Os, else the finished library may be missing implementations to standard functions, e.g. strlen. (I found out this the hard way...)
thanks for the patch now I'm wondering how I get the nano version of stdc++ (stdc++_nano, supc++_nano) also when I compile a mbed example project which build fine with "ARM GCC embedded compiler", I get linker errors: /usr/libexec/gcc/arm-none-eabi/ld: cannot find -lstdc++_nano /usr/libexec/gcc/arm-none-eabi/ld: cannot find -lsupc++_nano /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc_nano.a(lib_a-syscalls.o): In function `_lseek': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:282: multiple definition of `_lseek' ym/mbed-drivers/source/mbed-drivers.a(retarget.cpp.o):/home/bearsh/tmp/ble-examples/BLE_HeartRate/yotta_modules/mbed-drivers/source/retarget.cpp:324: first defined here /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc_nano.a(lib_a-syscalls.o): In function `findslot': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:90: multiple definition of `_open' ym/mbed-drivers/source/mbed-drivers.a(retarget.cpp.o):/home/bearsh/tmp/ble-examples/BLE_HeartRate/yotta_modules/mbed-drivers/mbed-drivers/FileHandle.h:105: first defined here ...
(In reply to Martin Gysel (bearsh) from comment #5) > thanks for the patch > > now I'm wondering how I get the nano version of stdc++ (stdc++_nano, > supc++_nano) > > also when I compile a mbed example project which build fine with "ARM GCC > embedded compiler", I get linker errors: > /usr/libexec/gcc/arm-none-eabi/ld: cannot find -lstdc++_nano > /usr/libexec/gcc/arm-none-eabi/ld: cannot find -lsupc++_nano > /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/ > libc_nano.a(lib_a-syscalls.o): In function `_lseek': > /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0. > 20160104/newlib/libc/sys/arm/syscalls.c:282: multiple definition of `_lseek' > ym/mbed-drivers/source/mbed-drivers.a(retarget.cpp.o):/home/bearsh/tmp/ble- > examples/BLE_HeartRate/yotta_modules/mbed-drivers/source/retarget.cpp:324: > first defined here > /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/ > libc_nano.a(lib_a-syscalls.o): In function `findslot': > /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0. > 20160104/newlib/libc/sys/arm/syscalls.c:90: multiple definition of `_open' > ym/mbed-drivers/source/mbed-drivers.a(retarget.cpp.o):/home/bearsh/tmp/ble- > examples/BLE_HeartRate/yotta_modules/mbed-drivers/mbed-drivers/FileHandle.h: > 105: first defined here > ... I'm having the same problem. I worked around it for now by symlinking libstdc++.a as libstdc++_nano.a, but it's ugly and it's not "nano". There's a similar bug filed at Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=1260439 The solution in theory would be to build libstdc++,libsupc++ twice when building cross GCC: once normal and once with -Os and whatever else makes up a nano libstdc++, perhaps -fno-exception -fno-rtti, but I am not very comfortable/confident messing around with the core toolchain eclasses and ebuilds..
(In reply to Martin Gysel (bearsh) from comment #5) > thanks for the patch > > now I'm wondering how I get the nano version of stdc++ (stdc++_nano, > supc++_nano) > > also when I compile a mbed example project which build fine with "ARM GCC > embedded compiler", I get linker errors: > /usr/libexec/gcc/arm-none-eabi/ld: cannot find -lstdc++_nano > /usr/libexec/gcc/arm-none-eabi/ld: cannot find -lsupc++_nano > /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/ > libc_nano.a(lib_a-syscalls.o): In function `_lseek': > /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0. > 20160104/newlib/libc/sys/arm/syscalls.c:282: multiple definition of `_lseek' > ym/mbed-drivers/source/mbed-drivers.a(retarget.cpp.o):/home/bearsh/tmp/ble- > examples/BLE_HeartRate/yotta_modules/mbed-drivers/source/retarget.cpp:324: > first defined here > /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/ > libc_nano.a(lib_a-syscalls.o): In function `findslot': > /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0. > 20160104/newlib/libc/sys/arm/syscalls.c:90: multiple definition of `_open' > ym/mbed-drivers/source/mbed-drivers.a(retarget.cpp.o):/home/bearsh/tmp/ble- > examples/BLE_HeartRate/yotta_modules/mbed-drivers/mbed-drivers/FileHandle.h: > 105: first defined here > ... The problems with multiple definition of syscalls are easiest to get rid of by adding EXTRA_ECONF="--disable-newlib-supplied-syscalls" to /etc/portage/env/cross-arm-none-eabi/newlib.conf in order to get rid of newlib's syscall implementation stubs, which you likely need to implement in any RTOS anyway. The problem is that when both the RTOS and newlib's implementations are placed in static libraries it becomes quite difficult to pick which implementation is the one that you want.. See for example http://comments.gmane.org/gmane.comp.gnu.binutils/71187 https://sourceware.org/ml/newlib/2015/msg00669.html
Btw, I just logged in to bugzilla right now, exactly to ask adding "--enable-newlib-io-long-long --enable-newlib-register-fini --disable-newlib-supplied-syscalls" options from ARM's official toolchain ;) Not sure, about first two (at least " io-long-long" can be usefull everywhere), but third one can be added in something like "if [ ${CHOST} = "arm-none-eabi" ]" block (or how do it named there). It'd be very good.
Created attachment 426172 [details, diff] newlib-nano-9999-r1.patch This is the version that I am currently using to build my toolchain. Apply it against the current newlib-9999.ebuild Added a USE flag for newlib-supplied-syscalls
yeah. It looks fine now (although, it'd be nice to port changes to stable and ~arch). But, there is also that (or related) problem: https://bugs.gentoo.org/show_bug.cgi?id=549512 // It seems, it is impossible to compile gcc[cxx] (libstdc++) on stage4 when newlib is built without supplied syscalls. Although, it is quite strange: ARM's toolchain is built without syscalls and WITH stdc++, gmp and so on...
Sorry, I forgot to add quote of stage4 build failure: > checking for gettimeofday... checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking for gettimeofday... yes > checking for library containing clock_gettime... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
I don't know the proper fix for the problem, but a quick workaround is to add EXTRA_ECONF="--enable-libstdcxx-time=no" to /etc/portage/env/cross-arm-none-eabi-elf/gcc.conf I don't know what the implications of changing this flag are, but from some quick googling it seems like it could possibly affect std::thread and std::chrono (C++11)
Created attachment 438094 [details, diff] newlib-nano-9999-r1.patch Updated patch to fix some issues with CFLAGS not being set correctly on the nano build. Now uses CFLAGS_FOR_TARGET to set -Os on the nano build.
Created attachment 441658 [details, diff] newlib-nano-9999-r1.patch Updated ebuild to place newlib-nano's newlib.h in include/newlib-nano/ instead of include/nano, since nano.specs in the current newlib git also points to include/newlib-nano/
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=791f828192341cfdbe896cd266b9e786ecb84e2e commit 791f828192341cfdbe896cd266b9e786ecb84e2e Author: Jason Zaman <perfinion@gentoo.org> AuthorDate: 2018-03-14 15:33:11 +0000 Commit: Jason Zaman <perfinion@gentoo.org> CommitDate: 2018-03-14 16:06:18 +0000 sys-libs/newlib: Add support for newlib-nano Closes: https://bugs.gentoo.org/532390 Package-Manager: Portage-2.3.24, Repoman-2.3.6 sys-libs/newlib/metadata.xml | 9 +++-- sys-libs/newlib/newlib-2.5.0.ebuild | 66 ++++++++++++++++++++++++++++++++++--- sys-libs/newlib/newlib-9999.ebuild | 66 ++++++++++++++++++++++++++++++++++--- 3 files changed, 130 insertions(+), 11 deletions(-)
