Bug 1260439 - nano libstdc++ is not included in package
Summary: nano libstdc++ is not included in package
Alias: None
Product: Fedora
Classification: Fedora
Component: arm-none-eabi-gcc-cs   
(Show other bugs)
Version: 22
Hardware: Unspecified Unspecified
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-09-06 21:39 UTC by Johnny Robeson
Modified: 2015-11-24 16:40 UTC (History)
3 users (show)

Fixed In Version: arm-none-eabi-gcc-cs-5.2.0-3.fc23 arm-none-eabi-gcc-cs-5.2.0-3.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-23 20:55:44 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to create missing c++ nano libs (2.83 KB, patch)
2015-10-30 07:09 UTC, Andy Green
no flags Details | Diff
Patch to create missing c++ nano libs v2 (3.97 KB, patch)
2015-11-05 04:30 UTC, Andy Green
no flags Details | Diff
Patch to create missing c++ nano libs V3 (4.03 KB, patch)
2015-11-05 04:51 UTC, Andy Green
no flags Details | Diff

Description Johnny Robeson 2015-09-06 21:39:46 UTC
Description of problem:

when building a package for arm-none-eabi I get this error:

/usr/lib/gcc/arm-none-eabi/5.2.0/../../../../arm-none-eabi/bin/ld: cannot find -lstdc++_nano

I'm going to be clear and say that I really have no idea which package should provide libstd++_nano.  I think that you need libstdc++ build for arm-none-eabi-gcc-cs, but I'm not entirely sure if that's where it should come from or not. I'm pretty stumped about where and what is needed for this to exist. 

I do know that the newlib package includes a nano.specs file that expects libstdc++_nano to exist as per this line:

%(nano_link) %:replace-outfile(-lc -lc_nano) %:replace-outfile(-lg -lg_nano) %:replace-outfile(-lrdimon -lrdimon_nano) %:replace-outfile(-lstdc++ -lstdc++_nano) %:replace-outfile(-lsupc++ -lsupc++_nano)

I can see that arm-none-eabi-gcc-cs does include a libstdc++.a, but then there's some message about how I really shouldn't use this package anyways (http://pkgs.fedoraproject.org/cgit/arm-none-eabi-gcc-cs.git/tree/bootstrapexplain?h=f22) and that it's only used for bootstrapping, so maybe we just need similiar nano logic as I put in newlib and then newlib needs to be rebuilt based on the bootstrapped compiler?

Here's how debian does it (afaict): http://anonscm.debian.org/cgit/collab-maint/libstdc++-arm-none-eabi.git/tree/debian/rules?id=33dc6d9d9bdb9f886a6827af661238184ef0e2d7

I probably didn't explain myself well here, because I don't really know what I'm talking about. Please ask me any clarifying questions.

Comment 1 Johnny Robeson 2015-10-06 04:08:40 UTC
so do you have any idea?

Comment 2 Johnny Robeson 2015-10-19 22:43:51 UTC
i looked at the build-bootstrap.sh from the gcc arm embedded build scripts and see they pass this to the 2nd gcc build "--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm"

Comment 3 Michael Lipp 2015-10-25 12:20:37 UTC
What I have understood so far: As the default (GNU) C library is too large for embedded systems, newlib (https://en.wikipedia.org/wiki/Newlib) was created. It still proved to be too large for some environments, which is why the derivative newlib-nano was created (https://github.com/32bitmicro/newlib-nano-1.0).

The space saving optimizations of newlib-nano seem to have been merged back into newlib (e.g. https://sourceware.org/ml/newlib/2014/msg00166.html). They can be activated by passing certain options to the configure script when preparing the library for built. So what we know as "newlib-nano" today is just newlib configured and built in a special way.

When providing pre-built packages, highly feature-configurable source code like newlib is a challenge because you have to choose a set of options for your distribution. In the case of a library provided for cross compiling, this is a special challenge because the configuration options chosen do not affect the host system. It's only when you deploy the code on the target system that you will note any differences. Of course, it is desirable that different distributions agree an a common set of configuration options for similar named packages to allow the (cross) developers to compile on different distributions easily.

Regarding newlib, both Ubuntu and Fedora (those are the ones that I use and know about) have chosen to provide two builds of newlib. You can easily see what happens in the Fedora spec file (http://pkgs.fedoraproject.org/cgit/arm-none-eabi-newlib.git/tree/arm-none-eabi-newlib.spec). Newlib is configured and built twice: once on a "build-newlib" directory and then for a second time with different configuration flags in a "build-nano" directory. The binary package consists of headers etc. from the "build-newlib" directory plus the libraries (*.a) from the "build-nano" with library files renamed from *.a to *_nano.a.

The problem with libstdc++ is that it depends on the C-library. As we have two flavors of the C-library in our cross compilation environment now (newlib and newlib_nano) libstdc++ might come in two flavors as well: a build using ("standard") newlib as C-library and a build using newlib with nano configuration as C-library. I' not sure whether you really need two flavors (see next paragraph). I would assume that the C++ library is based on the "official" API of the C-library only and that this API is provided by both flavors (i.e. configurations) of newlib. So it might be quite okay to have only one libstdc++.

The spec file of the arm-none-eabi-gcc-cs(-c++) package currently builds libcstd++ only once. Ubuntu does a different (better?) job here. The file referenced in the initial bug report (http://anonscm.debian.org/cgit/collab-maint/libstdc++-arm-none-eabi.git/tree/debian/rules?id=33dc6d9d9bdb9f886a6827af661238184ef0e2d7) shows that the "usual" build rules are modified in such a way that the build happens twice. Once with BUILDFLAGS and a second time with BUILDFLAGS_NANO. The latter use "-Os" instead of "-O2" and adds "-fno-exceptions -fshort-wchar". The libstdc++ compiled with the "stronger" optimizations is renamed to "libstdc++_nano.a" (actually there are additional, optional libraries that are compiled for a second time and renamed as well, but they aren't in our focus here).

So, as far as I have understood things, "libstdc++_nano.a" isn't a more space efficient implementation of the standard C++ library (at least not in the way as newlib_nano is compared to newlib). It is only more space efficient due to different compilation flags. I don't know if Fedora "has to" supply an optimized version of libstdc++ as Ubuntu does (if the version supplied works with both newlib and newlib_nano). But if it doesn't, the gcc nano.specs file has to be fixed!

Currently (newlib-2.2.0-1 and arm-none-eabi-gcc-cs-5.2.0-2), the nano.specs supplied with arm-none-eabi-newlib instructs the g++ linker to use "libc_nano.a" (instead of "libc.a"), which is okay, but it also instructs the linker to use "libstdc++_nano.a" (instead of "libstdc++.a") which is not okay if arm-none-eabi-gcc-cs doesn't supply such a library.

So, to summarize, either the libstdc++.a has to be built twice and supplied as libstdc++.a and libstdc++_nano.a by arm-none-eabi-gcc-cs, or the nano.specs provided by arm-none-eabi-newlib has to be changed (all this has to be done for all multi-libs, of course).

Comment 4 Johnny Robeson 2015-10-25 21:02:38 UTC
as far as the first section of the mail goes: I'm the one who added the initial nano support for libc, so I knew about that part :)

I think we should add the nano version of libstdc++ as many packaged versions of the compiler provide them too. Not only that, but more than a few makefiles for arm embedded stuff expect them to be there.

I'll look into what it takes to add them now that I"m more clear on how it works, unless you wanna give it a go.

Comment 5 Andy Green 2015-10-30 07:09 UTC
Created attachment 1087822 [details]
Patch to create missing c++ nano libs

I made the attached patch for this that creates an RPM with the pieces in, using the "build it twice" method.

And I confirmed the libstdc++_nano.a and libsupc_nano.a libraries work using mbed.

More info on the background here


Comment 6 Johnny Robeson 2015-10-30 07:27:02 UTC
I'm going to test this patch straightaway! Thanks!

PS: that's a really nice writeup you did there. If you wanna talk about mbed, then ping me on freenode as jrobeson.  

Your blog didn't have comments, so I'm mentioning this here: 

You can also debug without jtag via yotta debug OR simply install pyocd and run the pyocd-gdbserver and then connect to it.

Also, mbed-classic will be supported for some time to come, since not all boards can handle mbedos due to resource constraints.

Comment 7 Johnny Robeson 2015-10-30 07:28:53 UTC
oh, i realized something. the nano versions don't just have -fno-exceptions, they also tend to be compiled with -Os too.

Comment 8 Johnny Robeson 2015-10-30 07:41:51 UTC
Is there a (legal) way to get the codesourcery gcc version without signing up?

Comment 9 Andy Green 2015-10-30 07:43:41 UTC
Thanks... yes you are right about -Os.  I just left it to the Fedora distro defaults but since this is for a cross toolchain, that might not be ideal.

It seems to work OK without it but better to add it in.

Comment 10 Johnny Robeson 2015-10-30 07:52:04 UTC
oh duh, I"m sure i can find the the file i'm looking for on the fedora mirrors!

Comment 11 Andy Green 2015-10-30 08:01:37 UTC
yumdownloader --source <packagename>

still works even in these new days of DNF.  Then

rpm2cpio blah.rpm | cpio -id 

breaks it open and you can have the actual tarball.

Comment 12 Johnny Robeson 2015-10-30 08:31:19 UTC
also dnf download <package> --source

Comment 13 Andy Green 2015-11-05 04:30 UTC
Created attachment 1089943 [details]
Patch to create missing c++ nano libs v2

Attached an updated patch, which solves a DESTDIR lint problem from rpmbuild, and builds the nano libs with -Os

Comment 15 Andy Green 2015-11-05 04:51 UTC
Created attachment 1089944 [details]
Patch to create missing c++ nano libs V3

Sorry V3 is exactly the same as V2, but I removed the make -j20 hacks I left in on V2

Comment 16 Andy Green 2015-11-12 02:52:56 UTC
@Michal... is there something else I should be doing to get this patch or something like it applied?

It's not possible to develop with mbed3


on Fedora without also generating the C++ 'nano' libs.

Comment 17 Michal Hlavinka 2015-11-14 08:01:28 UTC
@Andy, nothing else. Sorry for late response and thanks for your help. Much appreciated

Comment 18 Fedora Update System 2015-11-14 08:05:49 UTC
arm-none-eabi-gcc-cs-5.2.0-3.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-f14847cd1c

Comment 19 Fedora Update System 2015-11-14 08:05:50 UTC
arm-none-eabi-gcc-cs-5.2.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-9f0bfdec67

Comment 20 Fedora Update System 2015-11-15 04:22:40 UTC
arm-none-eabi-gcc-cs-5.2.0-3.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update arm-none-eabi-gcc-cs'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-f14847cd1c

Comment 21 Fedora Update System 2015-11-15 05:25:43 UTC
arm-none-eabi-gcc-cs-5.2.0-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update arm-none-eabi-gcc-cs'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-9f0bfdec67

Comment 22 Fedora Update System 2015-11-23 20:55:40 UTC
arm-none-eabi-gcc-cs-5.2.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 23 Fedora Update System 2015-11-23 22:50:24 UTC
arm-none-eabi-gcc-cs-5.2.0-3.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.