http://bugzilla.opensuse.org/show_bug.cgi?id=936463 http://bugzilla.opensuse.org/show_bug.cgi?id=936463#c3 Andreas Färber changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |afaerber@suse.com Assignee|afaerber@suse.com |matz@suse.com --- Comment #3 from Andreas Färber --- (In reply to Michael Matz from comment #2)

Assigning to Andreas, he's the AVR interested person.

Nope, I have no AVR boards nor do I use icecream. (I was working on non-icecream cross-compilers in home:a_faerber:epiphany and home:a_faerber:rx projects.) Isn't avr an 8-bit microcontroller, whereas Linux only runs on avr32? In that case avr-suse-linux might indeed be wrong, as Richard suggests. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=936463 http://bugzilla.opensuse.org/show_bug.cgi?id=936463#c20 --- Comment #20 from Andreas Färber --- (In reply to Stanislav Brabec from comment #5)

The problem is not AVR specific. ARM is affected as well.

1) When trying to link, I get complain: armv7hl-suse-linux-gnueabi-gcc-5 main.c -o main Assembler messages: Fatal error: invalid -march= option: `armv7-a'

Well, the problem is different here. Links are provided, but elsewhere.

For AVR, symlinks are missing completely. For ARMV7HL, symlinks exist, but they are in a directory that is not tested.

Provided: /usr/arm-suse-linux-gnueabi/bin/as

Expected: /usr/lib64/gcc/armv7hl-suse-linux-gnueabi/5/as /usr/lib64/gcc/armv7hl-suse-linux-gnueabi/5/as /usr/lib64/gcc/armv7hl-suse-linux-gnueabi/as /usr/lib64/gcc/armv7hl-suse-linux-gnueabi/5/as /usr/lib64/gcc/armv7hl-suse-linux-gnueabi/as /usr/lib64/gcc/armv7hl-suse-linux-gnueabi/5/../../../../armv7hl-suse-linux- gnueabi/bin/armv7hl-suse-linux-gnueabi/5/as /usr/lib64/gcc/armv7hl-suse-linux-gnueabi/5/../../../../armv7hl-suse-linux- gnueabi/bin/as

I've confirmed this in home:a_faerber:uclinux. My solution is to add symlinks /usr/<mytriplet>/bin/as -> /usr/bin/arm-suse-linux-gnueabi-as and /usr/bin/<mytriplet>-strip -> /usr/bin/arm-suse-linux-gnueabi-strip etc. The former is needed for cc1 not to fall back to literal "as", i.e. /usr/bin/as, whereas the latter seems to be for the -as to find its -strip tool. Will doing this conditionally be acceptable? %if "%{gcc_target_arch}" != "%{binutils_os}" ... %endif Unfortunately that still means we can have one sysroot only for multiple gcc toolchains reusing the same assembler. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=936463 http://bugzilla.opensuse.org/show_bug.cgi?id=936463#c23 --- Comment #23 from Andreas Färber --- Stanislav, I just submitted https://build.opensuse.org/request/show/316396 containing some fixes for target installation part that may help your avr work as well. In particular usr/lib64/... was not searched inside the sysroot, only on the host, so we either need to install stuff in the places gcc expects them (as done here) or post-process those files by moving them around (seems much more work). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=936463 http://bugzilla.opensuse.org/show_bug.cgi?id=936463#c25 Stefan Brüns changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan.bruens@rwth-aachen.d | |e --- Comment #25 from Stefan Brüns --- (In reply to Richard Biener from comment #21)

As it works for me with some targets isn't it only a disconnect between the binutils and cross-gcc target triplets? There must be some configure magic to tell GCC not only about the build tools to use but about the tools to use in the installed system. --with-as/--with-ld might work here I guess? I really don't like the extra symlinks.

Or we want to forgo with the idea to have multiple cross toolchains for the "same" target (like armv6hl and armv7hl as they just differ in their set of default target options). Or we stop producing just a single cross-binutils package for them.

I also strongly prefer to have just one compiler for arm. Rationale: 1. cross-armv6hl-gcc and cross-armv7hl-gcc are essentially identical * same set of possible targets * both have "--with-float=hard" 2. everyone else uses an arm-<foo>-gnueabi triplet Only minor downside is a little bit of convenience, as one builds by default for the instruction set of the RPi1, the other one for everything else. -- You are receiving this mail because: You are on the CC list for the bug.