Re: Bug#341882: gcc-4.0: [mips] support for tri-arch on mips & mipsel
Stuart Anderson wrote:
> On Sat, 3 Dec 2005, Matthias Klose wrote:
>
> >why can't the biarch-include patch not be used?
>
> It probably can. This is likely the result of my attempts to keep my
> changes some what isolated early on. I'll have a look at reducing this
> to the existing biarch patch.
>
> >as we don't have all required libraries like zlib for biarch in lib,
> >some of with_lib32* and with_lib64* macros have to be disabled (or
> >maybe that's only the case for the gcc-4.1 packaging).
>
> Building gcc-4.0 does need the tri-arch version of libc6 (patches in
> 341884). Unfortunately, there does seem to be a bit of a chicken and egg
> problem on the first build. I'd be glad to provide a copy of my packages
> if that would help. gcc-4.0 doesn't seem to have a problem with missing
> libs other than the ones that are built as part of libc6, so the
> dependency on zlib may be a 4.1 issue.
>
> >>+# mips/mipsel build --------------------
> >>+ifneq (, $(filter $(DEB_TARGET_ARCH_CPU),mipsel))
> >>+ export GNUTARGET = elf64-tradlittlemips
> >>+endif
> >>+ifneq (, $(filter $(DEB_TARGET_ARCH_CPU),mips))
> >>+ export GNUTARGET = elf64-tradbigmips
> >>+endif
> >
> >where are these used?
>
> ar and ld get confused if they are not set. For some reason, it can't
> decide which binary format to use. It may be a binutils bug, but I was
> trying to not have to dig into that package and create a dependency on
> a specific patch level of yet another package.
If that's true it is a binutils bug. Ar and ld (are supposed to) default
to use the format of the first input object as output format. But I
wonder why "GNUTARGET = elf64-trad*mips" works for n32 then, it would
need elf32-ntrad*mips in that case.
Thiemo
Reply to: