[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Adding armel to dpkg and setting build cpu?



Hi
   I'm doing the Debian arm eabi port wiki.debian.org/ArmEabiPort, which is still for ARM processors but with a new incompatible ABI.
   I have got to the point where I need to modify dpkg and apt to add the new arch and would appreciate some guidance as to the best way to do this.

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.

A few terms:
- the new Debian architecture it has been "decided" will be called "armel", which seems awkward because "armeb" is already coded into many packages and means big-endian old-ABI... but I suppose it may all work out all right in the end.
- the minimum CPU for which we can currently compile for ARM EABI is armv4t (armv4 may be in the pipeline).
- the 4-part GNU/Autoconf configuration string for this arch is arm*-*-linux-gnueabi, which is ok. OS variants have been coded that way before: -gnulibc and -gnuuclibc spring to mind.

   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, 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

  In regular Debian etch I can see in /usr/share/dpkg/archtable

# <ignore>                      <Debian name>
i486-linux-gnu                  i386

ia64-linux-gnu                  ia64
alpha-linux-gnu                 alpha
arm-linux-gnu                   arm

so
I would have guessed that
arm-linux-gnueabi               armel
would be the one here (I gather the first column is obsolete these days) while in /usr/share/dpkg/cputable we have

# Column 1 is the Debian name for the CPU, used to form the architecture
# name.
# Column 2 is the GNU name for the CPU, used to output build and host
# targets in \xe2\x80\x98dpkg-architecture\xe2\x80\x99.
# Column 3 is an extended regular _expression_ used to match against the
# CPU part of the output of the GNU config.guess script.
#
# <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

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.

Finally there is /usr/share/dpkg/ostable with
# Column 1 is the Debian name for the system, used to form the
# architecture name.
# Column 2 is the GNU name for the system, used to output build and host
# targets in \xe2\x80\x98dpkg-architecture\xe2\x80\x99.
# Column 3 is an extended regular _expression_ used to match against the
# system part of the output of the GNU config.guess script.
#
# <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.

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?
-----------------

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.
  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. Do I need to configure the debian gcc to set the default CPU to our minimum too?

Lastly, what are armv4l and armv4b, as opposed to ARM instruction sets armv4, armv4t or cpu versions arm920t, xscale...

WHoo that's enough for now. Thanks for reading to the end.
I am following the list for now...

Bless

    M

Reply to: