From: "Thompson, David" <dthompson2@worcester.edu>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: [PATCH 2/5] gnu: Add avr-gcc.
Date: Mon, 30 May 2016 13:44:03 -0400 [thread overview]
Message-ID: <CAJ=RwfYGFG+BGYXUHKgTEhGhYD1=aDzUYsFEUue1nETEM-=gqQ@mail.gmail.com> (raw)
In-Reply-To: <87y48gje6d.fsf@gnu.org>
On Thu, Apr 14, 2016 at 1:25 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> David Thompson <dthompson2@worcester.edu> skribis:
>
>> * gnu/packages/avr.scm (avr-gcc): New variable.
>
> [...]
>
>> + `(modify-phases ,phases
>> + ;; Without a working multilib build, the resulting GCC lacks
>> + ;; support for nearly every AVR chip.
>> + (add-after 'unpack 'fix-genmultilib
>> + (lambda _
>> + (substitute* "gcc/genmultilib"
>> + (("#!/bin/sh") (string-append "#!" (which "sh"))))
>
> Just: (patch-shebang "gcc/genmultilib").
>
> I think the reason this file is not automatically patched during the
> ‘patch-shebangs’ phase is because it does not have the executable bit.
> Would be worth mentioning in a comment IMO.
>
> What’s unclear, though, is why the invalid shebang is a problem at all
> given that this file is not executable anyway. Thoughts?
It turns out that gcc/genmultilib is a script that generates many
scripts, and thus has many instances of #!/bin/sh in it. So,
patch-shebang was inadequate for the job and I've stuck with the
original solution.
>> + ((#:configure-flags flags)
>> + '(list "--target=avr"
>> + "--enable-languages=c,c++"
>> + "--disable-nls"
>> + "--disable-libssp"
>> + "--with-dwarf2"))))
>
> I think we should minimize target-specific changes and justify them in a
> comment when they’re unavoidable.
>
> Here, I think we can safely remove --target and --disable-nls.
> --disable-libssp and --enable-languages are already in
> ‘cross-gcc-arguments’, so that leaves us with just --with-dwarf2, IIUC.
>
> Why is it needed?
I've removed all of these.
>> + (native-search-paths
>> + (list (search-path-specification
>> + (variable "CROSS_CPATH")
>> + (files '("avr/include")))
>> + (search-path-specification
>> + (variable "CROSS_LIBRARY_PATH")
>> + (files '("avr/lib"))))))))
>
> That these go in ‘native-search-paths’ feels wrong.
>
> But I think it’s because we’re trying to build avr-libc like a “normal”
> package with a cross-toolchain as its input.
>
> Instead, the “intended use” is that libc is treated specially as in
> ‘cross-libc’ in cross-base.scm. Probably we need to:
>
> 1. Remove #:configure-flags and ‘native-inputs’ from the ‘avr-libc’
> package.
>
> 2. Add (supported-systems '()) or similar to the ‘avr-libc’ package.
>
> 3. Use something similar to ‘cross-libc’ but that uses avr-libc
> instead of glibc in cross-base.scm, thus setting CROSS_CPATH and
> CROSS_LIBRARY_PATH appropriately.
As explained in the thread about the avr-toolchain, this is a special
scenario because the only use for avr-gcc is to cross-compile and you
cannot actually port any part of Guix to the AVR architecture. Maybe
there's still something to revisit later, but having a working AVR
toolchain is a big win for now.
Pushed with the other issues addressed. Thanks!
- Dave
next prev parent reply other threads:[~2016-05-30 17:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-14 13:16 [PATCH 0/6] Fix AVR toolchain David Thompson
2016-04-14 13:17 ` [PATCH 1/5] gnu: Add avr-binutils David Thompson
2016-04-14 17:04 ` Ludovic Courtès
2016-04-14 18:32 ` Manolis Ragkousis
2016-04-19 14:55 ` Ludovic Courtès
2016-05-30 17:38 ` Thompson, David
2016-04-14 13:17 ` [PATCH 2/5] gnu: Add avr-gcc David Thompson
2016-04-14 13:53 ` Manolis Ragkousis
2016-04-14 13:55 ` Thompson, David
2016-04-14 17:06 ` Ludovic Courtès
2016-04-14 17:25 ` Ludovic Courtès
2016-05-30 17:44 ` Thompson, David [this message]
2016-06-01 21:21 ` Ludovic Courtès
2016-08-09 19:22 ` Danny Milosavljevic
2016-08-09 19:55 ` Ricardo Wurmus
2016-08-10 7:15 ` Danny Milosavljevic
2016-08-10 7:21 ` Danny Milosavljevic
2016-08-10 7:52 ` Ricardo Wurmus
2016-08-10 13:14 ` Thompson, David
2016-08-15 10:45 ` [PATCH] gnu: avr: Use the correct gcc version as native-input. This makes crtatmega32u4.o etc appear in the output Danny Milosavljevic
2016-08-15 11:34 ` Thompson, David
2016-08-15 18:48 ` Leo Famulari
2016-08-15 11:59 ` [PATCH 2/5] gnu: Add avr-gcc Danny Milosavljevic
2016-08-15 13:07 ` Thompson, David
2016-08-15 13:24 ` Danny Milosavljevic
2016-08-10 11:57 ` Vincent Legoll
2016-08-10 12:56 ` Ricardo Wurmus
2016-04-14 13:17 ` [PATCH 3/5] gnu: avr-libc: Fix build David Thompson
2016-04-14 14:02 ` Manolis Ragkousis
2016-04-14 17:26 ` Ludovic Courtès
2016-04-14 17:57 ` Thompson, David
2016-04-15 21:12 ` Ludovic Courtès
2016-05-30 17:40 ` Thompson, David
2016-04-14 13:17 ` [PATCH 4/5] gnu: Add avr-toolchain David Thompson
2016-04-14 17:33 ` Ludovic Courtès
2016-05-30 17:36 ` Thompson, David
2016-04-14 13:17 ` [PATCH 5/5] gnu: Remove xgcc-avr David Thompson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ=RwfYGFG+BGYXUHKgTEhGhYD1=aDzUYsFEUue1nETEM-=gqQ@mail.gmail.com' \
--to=dthompson2@worcester.edu \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).