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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]