Re: mips(el) n32 and n64 host triplet
On Fri, Mar 03, 2006 at 04:46:01PM +0100, Aurelien Jarno wrote: > >There are already triplets for this ;-) Take a look at the glibc > >configuration; I believe you'd want mips64-linux-gnuabi64 et al. > > > I can't find such thing in the glibc? In which file? Sorry, I missed this message (went in the wrong folder). Right now it's in ports/sysdeps/mips/preconfigure. See the switch on config_os. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mips(el) n32 and n64 host triplet
Daniel Jacobowitz a écrit :
On Wed, Mar 01, 2006 at 12:43:50PM +, Thiemo Seufer wrote:
I gave it some thought. Currently we only have mips64{,el}-linux-gnu,
which, to make matters worse, defaults to a n32 compiler with
multilibed o32/n32/n64 libraries. IMHO the best thing to do is to
introduce a completely separate set of triplets for the more advanced
single-ABI mips configurations. E.g:
mipsn32-linux-gnu
mipsn32el-linux-gnu
mipsn64-linux-gnu
mipsn64el-linux-gnu
The distinction between mips64 and mips_n_64 is a bit subtle, but
I don't see a better way while keeping the scheme relatively simple.
Comments?
There are already triplets for this ;-) Take a look at the glibc
configuration; I believe you'd want mips64-linux-gnuabi64 et al.
I can't find such thing in the glibc? In which file?
IMHO, this triplets have the advantage to be compatible with the current
config.{guess,sub}, and to be coherent with the new ARM ABI triplet,
which is arm-linux-gnueabi.
On the other side they look a bit strange...
Bye,
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mips(el) n32 and n64 host triplet
On Wed, Mar 01, 2006 at 03:50:15PM -0500, Daniel Jacobowitz wrote: > On Wed, Mar 01, 2006 at 04:14:44PM +, Thiemo Seufer wrote: > > Um. Actually, I'd like not to have mips64-linux-gnuabi32, but rather > > a convention which is acceptable over the whole toolchain. > > Why is this not acceptable over the whole toolchain? ISTR there was a arch-vendor-os-libc-abi quintuplet in use. Was that abandoned in favour of the approach you used? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mips(el) n32 and n64 host triplet
On Wed, Mar 01, 2006 at 04:14:44PM +, Thiemo Seufer wrote: > Um. Actually, I'd like not to have mips64-linux-gnuabi32, but rather > a convention which is acceptable over the whole toolchain. Why is this not acceptable over the whole toolchain? Alternatively, if you're only talking about the o32 case, then use mips-linux-gnu for that. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mips(el) n32 and n64 host triplet
On Wed, Mar 01, 2006 at 09:45:13AM -0500, Daniel Jacobowitz wrote:
> On Wed, Mar 01, 2006 at 12:43:50PM +, Thiemo Seufer wrote:
> > I gave it some thought. Currently we only have mips64{,el}-linux-gnu,
> > which, to make matters worse, defaults to a n32 compiler with
> > multilibed o32/n32/n64 libraries. IMHO the best thing to do is to
> > introduce a completely separate set of triplets for the more advanced
> > single-ABI mips configurations. E.g:
> >
> > mipsn32-linux-gnu
> > mipsn32el-linux-gnu
> > mipsn64-linux-gnu
> > mipsn64el-linux-gnu
> >
> > The distinction between mips64 and mips_n_64 is a bit subtle, but
> > I don't see a better way while keeping the scheme relatively simple.
> >
> > Comments?
>
> There are already triplets for this ;-) Take a look at the glibc
> configuration; I believe you'd want mips64-linux-gnuabi64 et al.
Um. Actually, I'd like not to have mips64-linux-gnuabi32, but rather
a convention which is acceptable over the whole toolchain.
Btw, the 'kern64' in that preconfigure looks like a bug, but appears
to be unused.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mips(el) n32 and n64 host triplet
On Wed, Mar 01, 2006 at 12:43:50PM +, Thiemo Seufer wrote:
> I gave it some thought. Currently we only have mips64{,el}-linux-gnu,
> which, to make matters worse, defaults to a n32 compiler with
> multilibed o32/n32/n64 libraries. IMHO the best thing to do is to
> introduce a completely separate set of triplets for the more advanced
> single-ABI mips configurations. E.g:
>
> mipsn32-linux-gnu
> mipsn32el-linux-gnu
> mipsn64-linux-gnu
> mipsn64el-linux-gnu
>
> The distinction between mips64 and mips_n_64 is a bit subtle, but
> I don't see a better way while keeping the scheme relatively simple.
>
> Comments?
There are already triplets for this ;-) Take a look at the glibc
configuration; I believe you'd want mips64-linux-gnuabi64 et al.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mips(el) n32 and n64 host triplet
Thiemo Seufer a écrit :
On Wed, Mar 01, 2006 at 12:23:35AM +0100, Aurelien Jarno wrote:
Hi all!
While thinking of multiarch, I remarked that there is no host triplet
for mips(el) using the n32 or the n64 ABIs. Both of them use
mips64-linux-gnu, at least it is what is done in the glibc, the
difference being done on the -mabi=n32 or -mabi=n64 option.
Multiarch is based on the fact there is no namespace collision of the
libraries are installed into (/usr)/lib/${host-triplet}.
Does host triplets have already been planned for these two possible
future ports?
I gave it some thought. Currently we only have mips64{,el}-linux-gnu,
which, to make matters worse, defaults to a n32 compiler with
multilibed o32/n32/n64 libraries. IMHO the best thing to do is to
introduce a completely separate set of triplets for the more advanced
single-ABI mips configurations. E.g:
mipsn32-linux-gnu
mipsn32el-linux-gnu
mipsn64-linux-gnu
mipsn64el-linux-gnu
The distinction between mips64 and mips_n_64 is a bit subtle, but
I don't see a better way while keeping the scheme relatively simple.
Comments?
That looks sane to me. If those names are accepted by everybody, I think
it would be good to add them in config.{guess,sub}, both in Debian and
in upstream. My experience in the GNU/kFreeBSD ports shows that it may a
long time to propagate to the packages, so it may be a good idea to do
that part now.
Then it would be possible to add them to dpkg, so that for example
'dpkg-architecture -qDEB_HOST_GNU_TYPE' returns 'mipsn64-linux-gnu'.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mips(el) n32 and n64 host triplet
On Wed, Mar 01, 2006 at 12:23:35AM +0100, Aurelien Jarno wrote:
> Hi all!
>
> While thinking of multiarch, I remarked that there is no host triplet
> for mips(el) using the n32 or the n64 ABIs. Both of them use
> mips64-linux-gnu, at least it is what is done in the glibc, the
> difference being done on the -mabi=n32 or -mabi=n64 option.
>
> Multiarch is based on the fact there is no namespace collision of the
> libraries are installed into (/usr)/lib/${host-triplet}.
>
> Does host triplets have already been planned for these two possible
> future ports?
I gave it some thought. Currently we only have mips64{,el}-linux-gnu,
which, to make matters worse, defaults to a n32 compiler with
multilibed o32/n32/n64 libraries. IMHO the best thing to do is to
introduce a completely separate set of triplets for the more advanced
single-ABI mips configurations. E.g:
mipsn32-linux-gnu
mipsn32el-linux-gnu
mipsn64-linux-gnu
mipsn64el-linux-gnu
The distinction between mips64 and mips_n_64 is a bit subtle, but
I don't see a better way while keeping the scheme relatively simple.
Comments?
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
