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ò
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 ) }
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. 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@fastmail.com> ;;; Copyright © 2020 Björn Höfling <bjoern.hoefling@bjoernhoefling.de> ;;; Copyright © 2021 Julien Lepiller <julien@lepiller.eu> +;;; Copyright © 2021 Morgan Smith <Morgan.J.Smith@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"))) \f -- 2.31.1
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --] 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 #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]