Subject: bug#47325: closed (Re: [PATCH] gnu: newlib-nano: Fix nano lib and header paths)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 13 Apr 2021 11:37:03 +0000

Your bug report

#47325: newlib-nano: are lib names wrong?

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
47325: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47325
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: [PATCH] gnu: newlib-nano: Fix nano lib and header paths
From: Efraim Flashner <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon, 12 Apr 2021 11:25:06 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

On Thu, Apr 08, 2021 at 09:02:20AM -0400, [email-masked] wrote:
> From: Morgan Smith <[email-masked]>
> 
> * gnu/packages/embedded.scm (newlib-nano-arm-none-eabi)[arguments]: Hard link
> library files from *.a to *_nano.a. Hard link newlib.h to a common location.
> ---
> 
> I CC'd Efraim because they commited my last gcc-arm-none-eabi patch. I hope
> that's ok. I'm not really sure who is responsible for this toolchain.
> 
> I successfully compiled some QMK firmware using this patch, something that
> failed previously.
> 

No one is really in charge of the cross toolchains, it's more of when it
becomes relevant to someone and it's time to fix something.

It looks good to me, I made a small change, changing link to symlink and
made the link relative. I thought about factoring out 'lib' or '.a' from
the find-files but ultimately decided against it, I think it's probably
easier to read as-is.

Patch pushed! Feel free to tag me on other ones like this too.

-- 
Efraim Flashner   <[email-masked]>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Subject: newlib-nano: are lib names wrong?
From: Nicolò Balzarotti <[email-masked]>
To: [email-masked]
Date: Mon, 22 Mar 2021 18:15:52 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi guix!

A program I'm packaging requires newlib-nano, but when building, the
linker fails to find g_nano and c_nano.

I found out those names are taken from the nano.specs file we install
> cat $(guix build newlib-nano)/arm-none-eabi/lib/nano.specs | grep -- -l

-lc_nano
%{specs=rdimon.specs:-lrdimon_nano} %{specs=nosys.specs:-lnosys}
%(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)
%{!shared:%{g*:-lg_nano} %{!p:%{!pg:-lc_nano}}%{p:-lc_p}%{pg:-lc_p}}

However, those files are missing:
> ls $(guix build newlib-nano)/arm-none-eabi/lib/ | grep lib

libc.a
libg.a
libgloss-linux.a
libm.a
libnosys.a
librdimon.a
librdimon-v2m.a
librdpmon.a

I was able to build the program by modifing the .specs file with:

(add-after 'install 'remove-suffix
           (lambda* (#:key outputs #:allow-other-keys)
             (substitute*
                 (string-append
                  (assoc-ref outputs "out")
                  "/arm-none-eabi/lib/nano.specs")
               (("_nano") ""))
             #t))

But reading online, it seems the _nano is a common suffix.  Should we
rename the output libs?  Should we symlink?  I know nothing about this,
but it might be a bug.

Thanks! Nicolò