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.
so do you have any idea?
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"
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).
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.
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 https://warmcat.com/embedded/iot/2015/10/29/the-mbed-maze.html
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.
oh, i realized something. the nano versions don't just have -fno-exceptions, they also tend to be compiled with -Os too.
Is there a (legal) way to get the codesourcery gcc version without signing up?
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.
oh duh, I"m sure i can find the the file i'm looking for on the fedora mirrors!
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.
also dnf download <package> --source
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
Packages for fc22 FYI: https://warmcat.com/arm-none-eabi-gcc-cs-5.2.0-2.fc22.src.rpm https://warmcat.com/arm-none-eabi-gcc-cs-5.2.0-2.fc22.x86_64.rpm https://warmcat.com/arm-none-eabi-gcc-cs-c++-5.2.0-2.fc22.x86_64.rpm https://warmcat.com/arm-none-eabi-gcc-cs-debuginfo-5.2.0-2.fc22.x86_64.rpm
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
@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 https://www.mbed.com/en/ on Fedora without also generating the C++ 'nano' libs.
@Andy, nothing else. Sorry for late response and thanks for your help. Much appreciated
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
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
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
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
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.
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.