Re: o32 != n32

James Cowgill <[email protected]>
Newsgroups gmane.linux.debian.ports.mips
Message-ID <[email protected]>
On Thu, 2015-05-07 at 12:01 +0200, Mathieu Malaterre wrote:
> On Thu, May 7, 2015 at 11:41 AM, James Cowgill <[email protected]> wrote:
> > On Thu, 2015-05-07 at 11:25 +0200, Mathieu Malaterre wrote:
> >> On Thu, May 7, 2015 at 10:57 AM, James Cowgill <[email protected]> wrote:
> >> > On Thu, 2015-05-07 at 09:27 +0200, Mathieu Malaterre wrote:
> >> >> Hello MIPS gurus,
> >> >>
> >> >> Could someone please let me know if this is possible to have a
> >> >> dual-ABI system (eg: n32 & o32) on MIPS. On my x86-64 system I can run
> >> >> a multi-arch system (x86 & x86-64), thanks to the recent multi-arch
> >> >> effort.
> >> >>
> >> >> Is it possible on MIPS ? Does it make sense ?
> >> >
> >> > If you have a 64-bit kernel then that should completely work (all Debian
> >> > kernels except for 4kc are 64-bit).
> >> >
> >> > If you then install gcc-multilib you should be able to pass -mabi=n32 to
> >> > gcc to get n32 binaries (or -mabi=64 for n64 binaries). I haven't done a
> >> > huge amount of testing with it, but you should also be able to add the
> >> > mips64el debian repo which contains everything recompiled with n64. Then
> >> > you should be able to do proper multiarch.
> >> >
> >> > See: http://mipsdebian.imgtec.com/
> >>
> >> I haven't received my Creator CI20 board yet, but I still fail to
> >> understand how that's possible. On my x86-64 there is a *single* ABI,
> >> and thus I can have a single `/usr/lib/x86_64-linux-gnu/libpthread.so`
> >> installed from libc6-dev:amd64 which wont conflict with
> >> `/usr/lib/i386-linux-gnu/libpthread.so` installed from libc6-dev:i386.
> >
> > The processor in the CI20 is 32-bit only so you won't be able to do any
> > of this on that unfortunately.
> >
> > If you use mipsel / mips64el multiarch, the setup use on amd64 is
> > identical on mips. Multilib places libraries in /lib32 or /lib64 just
> > link it does on x86.
> >
> >> I may sound dumb, but I fail to understand how multi-abi can be
> >> handled when directories are setup to handle (single) per-arch object
> >> files.
> >
> > The directories *are* setup to handle multiple ABIs. 'i386-linux-gnu' is
> > the ABI used on i386 and it is completely different to the
> > 'x86_64-linux-gnu' ABI (you can't link amd64 and i386 objects together).
> 
> My original post was about mixing n32 and o32. So if I try to
> summarize your post (little endian ABI only):
> 
> - debian `mipsel` refers to ABI `o32`
> - debian `mips64el` refers to ABI `o64`
> (https://gcc.gnu.org/projects/mipso64-abi.html)

mips64el uses n64, not o64.

> Debian has not been working officially on any of the n32 or n64 ABIs.

Well it's not in the main archive yet, but there are a number of people
working on it.

> Now let me rephrase my original question into:
> 
> Since Debian `mipsel` is using the old o32 ABI, would it make sense to
> use n32 ABI on Creator CI20 ?

n32 will not work on the CI20 because it only has a 32-bit processor.
n32 is a 64-bit ABI with 32-bit pointers (very similar to x32).

> As per your comment, I will not be able to use (=link to) the o32
> `libc` provided by the default debian `mipsel` package when building
> an n32 application (gcc -mabi=n32). In which case the location
> `/usr/lib/mipsel-linux-gnu/` will be reserved for object files with
> o32 ABI, while something like `/usr/lib/mipsel-n32-linux-gnu/` may be
> used for n32 ABI.

Yes that's correct. Bear in mind that there isn't a n32 debian port so
you'll have to compile any libraries you use (except glibc) yourself.

James
signature.asc (application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJVSzycAAoJENp9Vyz7AWUHYjQQALffASeI9Ozmh5qHg+YrDu9f
sL3UKXfayx98sQiQRWsaJGLllUFhhi1Qr/haexCjwqUT8XzLLAv5aMqaNorThW/q
im3KPiK7Wuvs+UT/0DZDrllXr9qyRzKWxwxQ00F4kiX7u1Kxg2Sgt+w94+DM8yzA
W7rr2EFEdtHJpxQtu51WBqLDUwlJyX+fofCEqxj0sOjiQlSMt8bIs0SIjExldPrv
lHOViKeaB/RWzhce+zWoV7AxGADLoHeDJZiDEbfZWNFjDYbwqfv6k+oEVnU0i8y9
1+ccWaloBbOCZjX9wHge1pV2i/+KEA6NOxA2E8Va/XXtsbYg+nLsc7L9ClzFCUzd
a4Cq17t504YW0OpNVBnlef49JsLKIPzUaBkWuCK3ER4BqRNZz7anZrmFjal4RbMf
E/+h34kFuVCjYwSF1xu0Q2O8yNlmhsK21AKUXuRR+GzdO6tYWkAPdA8Y57h4hrff
dB4EbMgmum3IwSY24/NCdO3QdQnVvF9+z77cCaGyIPJg93a7RSZIw2yBv6cZKJMH
bxePqO1Y3/dN7fSobUJLpDz20MZ4IUh7RZsfuYK9KrXFiwvAO6jngNQyK4XHonBx
z215UZJthV8agnFvAasqZNFRl6KqpJHj9oVyzxOVsN83gkfkzwFI2FVRF3XidXyC
KcxE70DFEH+nHnz7taDG
=TZSz
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.