Bug 723756 – sys-libs/newlib-3.3.0 fix for using nano.spec with c++ compiler

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description David Flogeras 2020-05-18 12:40:37 UTC]

The default nano.specs files installed by newlib will try to replace any linkage of libstdc++ and libsupc++ with a _nano appended to it.

Since Gentoo's cross gcc does not create a _nano version of these two libraries, you cannot use nano when building a C++ project.  This patch just removes the offending 'replace-outfile' directives in all nano.specs files installed.

Reproducible: Always

[Comment 1 David Flogeras 2020-05-18 12:41:21 UTC]

Created attachment 640146 [details, diff]
Patch for current in-tree newlib-3.3.0.ebuild

[Comment 2 Sergei Trofimovich (RETIRED) 2020-05-20 06:47:16 UTC]

The change makes sense. I'm surprised upstream gcc does not have _nano build variants by default. Why newlib relies on those to be present? Is it some sommon downstream change everyone does? Or just a newlib bug?

AFAIU 2 targets are affected: arc and arm:

"""
libgloss/arc/nano.specs:%(nano_link) %:replace-outfile(-lc -lc_nano) %:replace-outfile(-lg -lg_nano) %:replace-outfile(-lstdc++ -lstdc++_nano) %:replace-outfile(-lsupc++ -lsupc++_nano)

libgloss/arm/elf-nano.specs:%(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)
"""

[Comment 3 Larry the Git Cow 2020-05-20 07:26:16 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=78cd431b62a02ca951200937750ec24d47a3185a

commit 78cd431b62a02ca951200937750ec24d47a3185a
Author:     Sergei Trofimovich <[e-mail]>
AuthorDate: 2020-05-20 07:25:24 +0000
Commit:     Sergei Trofimovich <[e-mail]>
CommitDate: 2020-05-20 07:26:10 +0000

    sys-libs/newlib: don't use c++ _nano libs, bug #723756
    
    Gentoo's and upstream gccs don't install _nano variants of stdc++ and supc++.
    
    Let's not refer to them in nano specs of newlib until we do
    (or better yet upstream does) have these libraries.
    
    Reported-by: David Flogeras
    Closes: https://bugs.gentoo.org/723756
    Package-Manager: Portage-2.3.99, Repoman-2.3.22
    Signed-off-by: Sergei Trofimovich <[e-mail]>

 .../newlib/files/newlib-3.3.0-no-nano-cxx.patch    |  29 ++++
 sys-libs/newlib/newlib-3.3.0-r1.ebuild             | 154 +++++++++++++++++++++
 sys-libs/newlib/newlib-9999.ebuild                 |   4 +
 3 files changed, 187 insertions(+)

[Comment 4 David Flogeras 2020-05-20 07:48:01 UTC]

Sergei:

I agree, there should be a better upstream convention for _nano.  It seems that the "official" embedded arm gcc (developer.arm.com) builds their C++ libraries twice; and afaict the nano ones are compiled -Os (and maybe configured slightly differently).

That being said, I don't think newlib should hard rely on this behaviour/vendor.  Anyway, thanks for accepting (and solving the problem more elegantly than my patch).

[Comment 5 Sergei Trofimovich (RETIRED) 2020-05-20 22:30:59 UTC]

Aha, that makes sense. Thank you!