avr-gcc@5 is broken

avr-gcc cannot find device-specific libraries when compiling, which

from my reading is due to a problem with multilib. However, avr-gcc@4

works fine!

avr-gcc -O2 -DF_CPU=16000000UL -mmcu=atmega32u4 test.c -o test

avr-ld: cannot find -lm

avr-ld: cannot find -lc

avr-ld: cannot find -latmega32u4

collect2: error: ld returned 1 exit status

The libraries in question here are located within

/gnu/store/...-avr-libc-2.0.0/avr/lib/avr5 but avr-gcc is only

searching within /avr/lib.

For now, I'm just using avr-gcc@4 and moving on with life.

- Dave

As a workaround,

CPPFLAGS += -I${HOME}/.guix-profile/avr/include

LDFLAGS += -L${HOME}/.guix-profile/avr/lib/avr5 -L${HOME}/.guix-profile/avr/lib -B${HOME}/.guix-profile/avr/lib

works with avr-gcc 5.3.0. Unfortunately I don't know enough about avr-gcc to be able to permanently fix it.

I fixed part of it (I made it so that atmega32u4 exists in the first place) in master - but no idea what to do with the search path.

I'm pretty sure that if it uses CROSS_CPATH it's incorrect because cross-base has been changed from CROSS_CPATH to CROSS_C_INCLUDE_PATH, CROSS_CPLUS_INCLUDE_PATH etc in order to suppress warnings. If CROSS_C_INCLUDE_PATH overrides CROSS_CPATH (does it?) then setting CROSS_CPATH like avr.scm does does no good.

I propose to change it to the following:

On Mon, Sep 12, 2016 at 2:49 AM, Danny Milosavljevic

<dannym@scratchpost.org> wrote:

I don't know if this will have the intended effect and I cannot

experiment with it right now. Could you test? The LDFLAGS above

include the path to the device-specific object files (/avr5), but

avr-gcc is supposed to be able to figure that out on its own using a

"normal" library path, so I'm skeptical that simply changing the

search paths for the package is enough.

Thanks,

- Dave

On Mon, 12 Sep 2016 11:29:11 -0400

"Thompson, David" <dthompson2@worcester.edu> wrote:

(The patch: ) Can't test it right now (out of disk space; updating 2 GB texmf is really annoying) - but I tested it in the past and it wasn't sufficient. On the other hand, before the patch is applied, cross-gcc and avr.scm set *different* variables and that's probably incorrect.

I've used these LDFLAGS (actually used them as global flags for all gcc invocations) for some weeks with daily success. Also, the "-B" is necessary.

I think that the "native-search-paths" only affect the build system.

As far as I understand, avr-gcc is a "native" compiler in the sense of it-shouldn't-try-to-build-all-Guix-packages-for-it. And it's certainly set up as a "native" compiler. But that means that the avr-gcc port has to hack the search path that gcc usually uses for native compilers to make it search something else - not sure where they do and why it doesn't work for us. It would be good to locate this part.

The atmega32u4 comes from avr-libc (!) - that's why I changed avr-libc to use the same compiler (already in master for some months). That made it work much better.

I hope someone can shed a light on this.

cross-base does).

(avr-gcc-5)[source]: Apply patch "gcc-cross-environment-variables.patch".

---

gnu/packages/avr.scm | 16 ++++++++++++++--

1 file changed, 14 insertions(+), 2 deletions(-)

Hi,

I verified that this patch works[1]. Could you please push to master?

Thanks! :-)

Hi Arun,

pushed to guix master as commit 2f3515f7369d91d8922620044f9348cc727b6c10.

Closing this bug as fixed.

--

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