GNU bug report logs - #47325
newlib-nano: are lib names wrong?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47325 in the body.
You can then email your comments to 47325 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolò Balzarotti <anothersms <at> gmail.com>
To: bug-guix <at> gnu.org
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ò

Message #8 received at 47325 <at> debbugs.gnu.org (full text, mbox):

From: Morgan Smith <Morgan.J.Smith <at> outlook.com>
To: anothersms <at> gmail.com
Cc: 47325 <at> debbugs.gnu.org
Subject: Re: bug#47325: newlib-nano: are lib names wrong?
Date: Fri, 26 Mar 2021 16:42:40 -0400

Hello Nicolò,

This is definitely a bug that I encountered today. I'm convinced it's a
bug because I came across this page that says so:
https://newlib.sourceware.narkive.com/kfT8XDEe/building-libc-nano-and-libg-nano

The git repo it links to has the following shell function. I think we
should emulate its behavior.

(On a slightly unrelated note, can someone PLEASE accept my patch in bug
44750 for a different arm-none-eabi issue. It's desperately needed.)

copyNanoLibraries() {
	(
	source="${1}"
	destination="${2}"
	messageA "\"nano\" libraries copy"
	multilibs=$("${destination}/bin/${target}-gcc" -print-multi-lib)
	sourcePrefix="${source}/${target}/lib"
	destinationPrefix="${destination}/${target}/lib"
	for multilib in ${multilibs}; do
		multilib="${multilib%%;*}"
		sourceDirectory="${sourcePrefix}/${multilib}"
		destinationDirectory="${destinationPrefix}/${multilib}"
		mkdir -p "${destinationDirectory}"
		cp "${sourceDirectory}/libc.a" "${destinationDirectory}/libc_nano.a"
		cp "${sourceDirectory}/libg.a" "${destinationDirectory}/libg_nano.a"
		cp "${sourceDirectory}/librdimon.a" "${destinationDirectory}/librdimon_nano.a"
		cp "${sourceDirectory}/libstdc++.a" "${destinationDirectory}/libstdc++_nano.a"
		cp "${sourceDirectory}/libsupc++.a" "${destinationDirectory}/libsupc++_nano.a"
	done

	mkdir -p "${destination}/${target}/include/newlib-nano"
	cp "${source}/${target}/include/newlib.h" "${destination}/${target}/include/newlib-nano"

	if [ "${keepBuildFolders}" = "n" ]; then
		messageB "\"nano\" libraries remove install folder"
		maybeDelete "${top}/${buildNative}/${nanoLibraries}"
	fi
	)
}

Message #11 received at 47325 <at> debbugs.gnu.org (full text, mbox):

From: Morgan.J.Smith <at> outlook.com
To: 47325 <at> debbugs.gnu.org
Cc: Morgan Smith <Morgan.J.Smith <at> outlook.com>, efraim <at> flashner.co.il,
 anothersms <at> gmail.com
Subject: [PATCH] gnu: newlib-nano: Fix nano lib and header paths
Date: Thu,  8 Apr 2021 09:02:20 -0400

From: Morgan Smith <Morgan.J.Smith <at> 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.


 gnu/packages/embedded.scm | 36 +++++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/embedded.scm b/gnu/packages/embedded.scm
index a3f1d85580..ea5bfdbdd1 100644
--- a/gnu/packages/embedded.scm
+++ b/gnu/packages/embedded.scm
@@ -8,6 +8,7 @@
 ;;; Copyright © 2020 Marius Bakke <mbakke <at> fastmail.com>
 ;;; Copyright © 2020 Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de>
 ;;; Copyright © 2021 Julien Lepiller <julien <at> lepiller.eu>
+;;; Copyright © 2021 Morgan Smith <Morgan.J.Smith <at> outlook.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -229,7 +230,40 @@ (define-public newlib-nano-arm-none-eabi
            "--enable-lite-exit"
            "--enable-newlib-global-atexit"
            "--enable-newlib-nano-formatted-io"
-           "--disable-nls"))))
+           "--disable-nls"))
+       ((#:phases phases)
+        `(modify-phases ,phases
+           ;; XXX: Most arm toolchains offer both *.a and *_nano.a as newlib
+           ;; and newlib-nano respectively.  The headers are usually
+           ;; arm-none-eabi/include/newlib.h for newlib and
+           ;; arm-none-eabi/include/newlib-nano/newlib.h for newlib-nano.  We
+           ;; have two different toolchain packages for each which works but
+           ;; is a little strange.
+           (add-after 'install 'hardlink-newlib
+             (lambda* (#:key outputs #:allow-other-keys)
+               (let ((out (assoc-ref outputs "out")))
+                 ;; The nano.specs file says that newlib-nano files should end
+                 ;; in "_nano.a" instead of just ".a".  Note that this applies
+                 ;; to all the multilib folders too.
+                 (for-each
+                  (lambda (file)
+                    (link file
+                          (string-append
+                           ;; Strip ".a" off the end
+                           (substring file 0 (- (string-length file) 2))
+                           ;; Add "_nano.a" onto the end
+                           "_nano.a")))
+                  (find-files
+                   out
+                   "^(libc.a|libg.a|librdimon.a|libstdc\\+\\+.a|libsupc\\+\\+.a)$"))
+
+                 ;; newlib.h is usually in this location instead so both
+                 ;; newlib and newlib-nano can be in the toolchain at the same
+                 ;; time
+                 (mkdir (string-append out "/arm-none-eabi/include/newlib-nano"))
+                 (link (string-append out "/arm-none-eabi/include/newlib.h")
+                       (string-append out "/arm-none-eabi/include/newlib-nano/newlib.h"))
+                 #t)))))))
     (synopsis "Newlib variant for small systems with limited memory")))
 
 
-- 
2.31.1

Message #16 received at 47325-done <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Morgan.J.Smith <at> outlook.com
Cc: 47325-done <at> debbugs.gnu.org, anothersms <at> gmail.com
Subject: Re: [PATCH] gnu: newlib-nano: Fix nano lib and header paths
Date: Mon, 12 Apr 2021 11:25:06 +0300

[Message part 1 (text/plain, inline)]

On Thu, Apr 08, 2021 at 09:02:20AM -0400, Morgan.J.Smith <at> outlook.com wrote:
> From: Morgan Smith <Morgan.J.Smith <at> 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 <at> 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

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.