Re: avr-gcc

[Thompson, David]

On Wed, Nov 18, 2015 at 6:03 AM, Ludovic Courtès <address@hidden> wrote:
> "Thompson, David" <address@hidden> skribis:
>
>> On Tue, Nov 17, 2015 at 4:32 PM, Ludovic Courtès <address@hidden> wrote:
>
> [...]
>
>>> In GCC we modify the spec file so that the right -L/libc/dir/name is
>>> passed to ld; see (gnu packages gcc), ‘GNU_USER_TARGET_LIB_SPEC’.
>>>
>>> However, ‘gcc-cross-sans-libc-avr’ is a bare-bones compiler, so it
>>> doesn’t get the -L flag in question since there’s no libc to link to.
>>>
>>> To get a full-blow compiler that uses avr-libc, you could start from
>>> this:
>>>
>>>
>>>
>>> … and then address any glibc assumptions you encounter.
>>
>> I tried to do this, but I don't really know what I'm doing.  The first
>> problem I encountered was that I needed to add a case to the
>> 'glibc-dynamic-linker' procedure in (gnu packages bootstrap).  I
>> didn't know what ld was needed, if any, so I added this case:
>>
>>     ((string=? system "avr-avrlibc") "no-ld.so")
>
> It may be that avr-libc has no dynamic linker, because it targets
> MMU-less systems, no?
>
>> Then, the issue was that avr-libc doesn't have a propagated input with
>> the label "linux-headers", as required by 'cross-gcc' in (gnu packages
>> cross-base).  So, as a hack I tried something like this:
>>
>>     (if (string=? "avr-libc" (package-name libc))
>>                            `()
>>                            `(("xlinux-headers" ;the target headers
>>                               ,@(assoc-ref (package-propagated-inputs libc)
>>                                            "linux-headers"))))
>>
>> Now I was able to get the build process to start, but it failed when
>> trying to compile binutils:
>>
>>     checking target system type... Invalid configuration
>> `avr-linux-avrlibc': system `avrlibc' not recognized
>>
>> I'm totally lost.  Any thoughts on where to go next?
>
> Hmm, maybe my suggestion was just misguided, because the AVR environment
> seems to be very different from the typical GNU/Linux environment.
>
> For instance it’s not clear to me how as a user you’re supposed to tell
> the compiler which libc.a file to choose among all those provided by
> avr-libc.
>
> Back to the Microscheme question, you could set ‘CROSS_LIBRARY_PATH’
> manually to point to one of the avr/lib/xxx directories, where our
> cross-gcc will find libc.a, libm.a, and crt*.o, but I don’t know if it’s
> how it’s intended to work.
>
>> BTW, I believe this native search path is needed in order for the AVR
>> header files to be found:
>>
>>     (search-path-specification
>>      (variable "C_INCLUDE_PATH")
>>      (files '("avr/include")))
>
> ‘C_INCLUDE_PATH’ is the C-only equivalent of ‘CPATH’.  Our
> cross-compiler honors ‘CROSS_CPATH’ instead of ‘CPATH’ so as to
> distinguish between host and build headers (see
> gcc-cross-environment-variables.patch.)

Ah, okay.  CROSS_CPATH works.

> Also it’s not clear to me why avr-libc installs things in avr/include
> instead of include/.

Not sure either, but it poses no problem.

> So in short, it looks like everything you need is already there, but the
> pieces need to be wired together.  :-)

Not quite.  The avr-gcc build only provides a single version of
libgcc.a, whereas Debian's avr-gcc provides a separate libgcc.a for
each supported AVR family (avr2, avr3, avr35, etc.)  Mark thought it
might be the fault of the --disable-multilib configure flag, so I
removed it but it didn't solve anything.  I'm not sure what to do now.
I have no idea what flag or patch could be signalling to the gcc build
system that it shouldn't try to compile libraries for all of the
various AVR models.

Does anyone have any ideas?

Thanks,

- Dave