Re: Adding armel to dpkg and setting build cpu?
On Sat, 2006-11-18 at 19:56:03 +0000, Martin Guy wrote:
> My two questions are basically how/where I should implement the new arch
> name, and how I set the cpu version for which packages will be compiled.
> Anyway, Nokia have already implemented something close in structure to
> Debian ARM EABI in their "mistral" distribution of "maemo" and they call
> their packages *_armel.deb. However, instead of adding armel to
> /usr/share/dpkg/archtable,
This file only lists official architectures currently present in the
archive.
> they have hard-coded tests for "armel" and "-gnueabi" into the apt and
> dpkg scripts, which seems to work but doesn't seem right. There's a
> quick summary of what they've done to dpkg here:
> http://cluster.aleph1.co.uk/~martin/packages/dpkg.txt
I know it does not seem right, I did the changes, they were mostly a
proof of concept, that's why I've not merged them in dpkg upstream yet,
but the only problem I see right now is in the way it's implemented in
the scripts not on the concept itself.
> while in /usr/share/dpkg/cputable we have
> # <Debian name> <GNU name> < config.guess regex>
> i386 i486 (i[3456]86|pentium)
> ia64 ia64 ia64
> alpha alpha alpha.*
> amd64 x86_64 x86_64
> armeb armeb arm.*b
> arm arm arm.*
>
> so I guess
> armel armv4t ?????
> Is this used to match on config.guess output and derive the debian arch? If
> so we're stuck, cos on current arm etch on an armv4t we get
> armv4l-unknown-linux-gnu while current armel systems give
> armv6l-unknown-linux-gnu or armv5tejl-unknown-linux-gnu
No, an armel system should give arm.*-.*-linux-gnueabi. But anyway
changing cputable is wrong, because of the matching, and because armel
does not magically change of cpu type. Also the Debian cpu name does
not need to match the Debian architecture name, even if they happen to
be the same in all current linux arches.
> Again, in the apt sources there is buildlib/archtable with
> i.86 i386
> pentium i386
> ...
> arm.*b armeb
> arm.* arm
>
> I'm probably getting confused here between debian arch names and gnu cpu
> names. Frinstance, armeb is recognised as a GNU cpu name, but armel isn't.
Because there's no such thing, armel is just a symbolic name we gave
to the port, it could be foo as well.
> Finally there is /usr/share/dpkg/ostable with
> # <Debian name> <GNU name> < config.guess regex>
> linux linux-gnu linux[^-]*(-gnu.*)?
> darwin darwin darwin[^-]*
> freebsd freebsd freebsd[^-]*
>
> which Nokia have modified to:
> gnueabi-linux linux-gnueabi linux[^-]*-gnueabi
> gnu-linux linux-gnu linux[^-]*(-gnu)?
> none-darwin darwin darwin[^-]*
> none-freebsd freebsd freebsd[^-]*
>
> which is fair enough, since gnueabi is the OS variant, the same as gnulibc1,
> gnuuclibc and so on, though dpkg-unstable has not gone this way.
... yet. The thing here, is that for armel, the cpu does not change, only
the ABI which is contained in the libc/kernel part in the GNU triplet,
as that convention comes from those components anyway.
> I mean, I can just make patches to apply their modifications, full of "case
> armel" and "if arm-linux-gnueabi" clauses, but there may be a better way.
> I notice that this seems to be the first time that a Debian architecture
> name has been "chosen" that is not a valid first part of a GNU configuration
> string. Is that why it has to be done with case statements and ifs?
Yes, but the problem comes from the assumption that the Debian arch is
just the cpu name, that's wrong.
The changes I made to m4/arch.m4 recently in sid's dpkg makes it not
need changes anymore. Also for apt, I'm going to propose to use
dpkg-architecture instead of their local tables, so that that knowledge
is just in one place, which is what we did in Maemo.
I've a cleaner implementation locally which uses an alias table to
move some of those ifs there and a Debian triplet internally to map
things from the GNU triplet to the Debian arch, which I'll be applying
once we branch for lenny after the upload for etch is done.
> That's one. The other one is more of a debian newbie question: where do I
> set the minimum cpu that packages are compiled for? This must already happen
> for debian i386 arch to compile for i486 cpu on pentium-4 boxes, and on
> current arm architecture to compile for armv3 on armv5t boxes.
You define that on gcc.
> What about sourec packages that do not use "configure" but just blindly
> compile with the system gcc? On x86 this is ok because the default cpu is
> i386, but on GCC-4.1 the default ARM cpu is armv5t.
On x86 the default cpu is i486, we don't support pure i386 anymore,
you can check with 'gcc -dumpmachine'.
> Do I need to configure the debian gcc to set the default CPU to our
> minimum too?
Yes.
> Lastly, what are armv4l and armv4b, as opposed to ARM instruction sets
> armv4, armv4t or cpu versions arm920t, xscale...
I'd assume armv4 little or big endian.
regards,
guillem
Reply to: