http://bugzilla.novell.com/show_bug.cgi?id=936463
http://bugzilla.novell.com/show_bug.cgi?id=936463#c21
--- Comment #21 from Richard Biener
(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.
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. -- You are receiving this mail because: You are on the CC list for the bug.