Tri-arch support on mips(el) (was Bug#325226: libc6: Wrong dynamic linker on amd64)
Thiemo Seufer a écrit :
The three mips ABIs are o32 (fully 32bit), n32 (32bit address space,
64bit register width) and n64 (fully 64bit). n32 traditionally uses
The general problem with this approach is that it doesn't scale beyond
2-3 ABIs, and requires a "native" ABI definition. The multi-arch
approach tries to do better (but needs more work before it can
provide a viable alternative).
Speaking about that, what is the current status for the tri-arch
support? Last news about that seems to be the mails on the list in November.
If we really want such support for Etch, and given the fact that the
toolchain will be frozen in July, we should start to merge it.
AFAIK, only glibc and gcc needs patching.
Even if nobody answered about the patch for glibc (#341884), it looks
ok, at least for me.
Concerning the patch for gcc (#341882), there was a lot of discussion.
Stuart Anderson has posted a patch in December, which seems to fix all
discussed problems, except those parts:
> +! MULTILIB_DIRNAMES = n32 32 64
> +! MULTILIB_DIRNAMES = 32 . 64
Daniel Jacobowitz explained some concerns about that, but Stuart give an
explanation. Should this be considered ok?
+# mips/mipsel build --------------------
+ifneq (, $(filter $(DEB_TARGET_ARCH_CPU),mipsel))
+ export GNUTARGET = elf64-tradlittlemips
+ifneq (, $(filter $(DEB_TARGET_ARCH_CPU),mips))
+ export GNUTARGET = elf64-tradbigmips
This part seems to be too workaround a bug in binutils, Thiemo said. Has
somebody worked on a fix?
Also, I am ready to give some help there. I am first trying to build the
gcc and glibc packages on a mips, but I face a chicken and egg problem
here. Does anybody already have glibc and/or gcc packages for mips? If
not, what is the easiest way to make the bootstrap?
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' firstname.lastname@example.org | email@example.com
`- people.debian.org/~aurel32 | www.aurel32.net