emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47325: closed (newlib-nano: are lib names wrong?)


From: GNU bug Tracking System
Subject: bug#47325: closed (newlib-nano: are lib names wrong?)
Date: Tue, 13 Apr 2021 11:37:02 +0000

Your message dated Mon, 12 Apr 2021 11:25:06 +0300
with message-id <YHQD4sNsSsKumMU/@3900XT>
and subject line Re: [PATCH] gnu: newlib-nano: Fix nano lib and header paths
has caused the debbugs.gnu.org bug report #47325,
regarding newlib-nano: are lib names wrong?
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
47325: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47325
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: newlib-nano: are lib names wrong? Date: Mon, 22 Mar 2021 18:15:52 +0100
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ò



--- End Message ---
--- Begin Message --- Subject: Re: [PATCH] gnu: newlib-nano: Fix nano lib and header paths Date: Mon, 12 Apr 2021 11:25:06 +0300
On Thu, Apr 08, 2021 at 09:02:20AM -0400, Morgan.J.Smith@outlook.com wrote:
> From: Morgan Smith <Morgan.J.Smith@outlook.com>
> 
> * 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   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Attachment: signature.asc
Description: PGP signature


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]