nano.specs not using the nano version of the C++ libraries

[ilg-ul]

I've just built a new version of the RISC-V bare-metal toolchain, using GCC 11.3 and the latest newlib, including the newlinb-nano libraries, and I noticed that the nano.spec does not replace the -lstdc++ and -lsupc++ with their size optimised nano versions, as the Arm bare-metal toolchains do.

For example, the arm-none-eabi toolchains uses:

*link:
%(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)

while the riscv-none-embed toolchain uses:

*link:
%(nano_link) %:replace-outfile(-lc -lc_nano) %:replace-outfile(-lg -lg_nano) %:replace-outfile(-lm -lm_nano)

Could we add the same substitutions to the RISC-V newlib in order to make applications using newlib-nano benefit from the size optimised versions of the C++ libraries?

If so, what is the procedure to get such a patch accepted upstream?

[ilg-ul]

If this repo is deprecated, can you suggest the right one?

[jim-wilson]

This repo isn't dead, but there has always been a shortage of people helping to maintain it, which is probably worse now that I'm "retired". Also, I've had an out of town visitor for the last 2 weeks, and was in Las Vegas before that, so I'm about a month behind in handling stuff.

We currently build newlib twice, once regular, and once nano, then rename files from the nano build to have a nano extension, so we have both regular and nano versions of newlib that we can use when linking. However, we only build libstdc++ and libsupc++ once. We would need Makefile changes to build a second version of these libraries. Since the gcc makefile doesn't support building them twice, we probably need to build the stage2 gcc twice, and then rename files from the second build. That would be a project, not just a simple bug fix. Then we need to fix the libgloss nano.spec file upstream, and backport into riscv-gnu-toolchain.

Not clear how useful that would be, since nano is for reducing code size, and there is no code size reduced version of libstdc++ unless someone does major work on it, which is an even bigger project. If ARM has already done some work in this area, then someone needs to reverse engineer what they did so that we can do the same thing for RISC-V.

None of this is likely to happen unless someone volunteers to do the work.

[ilg-ul]

there is no code size reduced version of libstdc++ unless someone does major work on it

No need for any major work, just compile the nano version of stage2 with -Os, and the regular one with -O3.

If ARM has already done some work in this area ...

The Arm embedded toolchains had this feature from the very beginning, and my RISC-V toolchains always built the stage2 twice, to discover now that the nano variant is ignored, because the specs file does not consider it. :-(

Assuming the specs file is patched upstream, the rest is peanuts.

[ilg-ul]

I think that for my binary distribution the simplest workaround is to patch that specs file after archive download.

If you'll ever update the upstream file, the patch will become ineffective.

[ilg-ul]

I applied a run-time patch and temporarily fixed the problem:

• https://github.com/xpack-dev-tools/build-helper/blob/d7bd424855f86868a3ea41c35c2d193c37bf05ea/common-apps-functions-source.sh#L2350-L2375

However I still suggest to fix the upstream configuration, and bring it in line with the Arm configuration.

[kito-cheng]

IIUC, that also require build script modification to building -lstdc++_nano and -lsupc++_nano rather than just adding that to spec file?

[ilg-ul]

I don't know about your build scripts, but for the xPack RISC-V toolchain I use exactly the same scripts as for the Arm toolchain, and the nano versions of the C++ libraries are built anyway.