[Top] [All Lists]

Re: A question about architecture and byte order with RPMs

Subject: Re: A question about architecture and byte order with RPMs
From: Alex deVries <>
Date: Thu, 4 Dec 1997 12:04:36 -0500 (EST)
Cc: SGI Linux <>,
In-reply-to: <>
On Thu, 4 Dec 1997 wrote:
> On Thu, Dec 04, 1997 at 12:31:05AM -0500, Alex deVries wrote:
> > Is the creation of a mipsel type reasonable?
> Definately, only the fact that there are more important things to do did
> so far keep me from doing so.

> While almost all MIPS CPUs can run in both byteorder some systems like
> the Acer Pica or DECstations don't support this CPU feature.  There is

Right.  So they'd be of arch 'mips'.

> still another CPU feature that allows to run the other flavor of software
> in usermode but supporting it not a Sunday afternoon hack.  

Hm.  RPM makes no diffrentiation between user and non-usermode apps.  So,
I'd say we'd mark this as 'mipsbi'.  The only restriction is with kernel
RPMs, and there aren't a lot of those.

> It requires
> going through _all_ the kernel code and possibly fixing the byteorder
> handling.

Nobody wants that.

> Unless the rpm gurus think there is a better way to do things - yes, it
> looks right to me.  The other thing that needs to be done is to teach
> rpm how to recognice the various system flavours.  Currently rpm relies
> on uname() returning "mips" and therefore thinks MIPS is always MIPS.

That shouldn't be too difficult to build into .configure.  For everything
matching mips:*, configure should do a byte order execution check. If it
can do mipsel, it's little endian.  If it can do bigendian, it's mips.  If
it can do both, it's mipsbi.  Is there an easy way to do a test like
this, Ralf?

> Have to take a look at the rpm sources - is there an official way to
> teach rpm about incompatible variants of the same CPU architecture?

Yes, sort of.

There should be two binary formats defined in /usr/lib/rpmrc
arch_canon: mips: mips 4 (already defined)
arch_canon: mipsel: mipsel 11 

arch_compat: mips: noarch 
arch_compat: mipsel: noarch 
arch_compat: mipsbi: mips mipsel

> Modifying uname() to return "mipsel" etc. is a bad choice.  For most

I agree.  I think we should just patch the configure script to do a
translation to mips, mipsel or mipsbi, as I described above.

- Alex

<Prev in Thread] Current Thread [Next in Thread>