Comment # 21 on bug 936463 from
(In reply to Andreas F�rber from comment #20)
> (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: