Re: Deciding new arm EABI port name
Hi,
Agreed with guillem that we'll decide this at the Extremadura
meeting next week, else we'll end up like the amd64 port with
flaming for the name choice in tech-ctte..
> >should be clear why current dpkg-architecture limits our choices.
(emphasize on current)
> <rant>
> Pardon me, but to me it looks outright stupid to let development be
> constrained by some perl script.
Well it's free software, so we can change it to whatever we want =)
The big but is that it is also a very important interface, and changes
should be done with care.
> I would want to install a Debian distribution compiled with
> -march=armv5te -mtune=xscale -Wa,-mcpu=xscale on a newer iPAQ
> and another one compiled with -march=armv4 -mtune=strongarm1100
> on my older iPAQ.
Thats unreleated to architecture strings. It's worth remembering
that compliler flags rea turn O(n^2) solutions into O(1) solutions. The
linear max 5% increase will not solve the real big performance
problems.
> Attaching patches for -softfloat and -uclibc... With these patches,
> this is what my local dpkg-architecture says (DEB_BUILD lines removed):
These are nice, but did you test if they work with the autodetection
from compiler? with -a flag things seem work more easily..
> I would expect arm-eabi to look like this:
> $ dpkg-architecture -aarm-eabi
> DEB_HOST_ARCH=arm-eabi
> DEB_HOST_ARCH_OS=linux-eabi
> DEB_HOST_ARCH_CPU=arm
> DEB_HOST_GNU_CPU=arm
> DEB_HOST_GNU_SYSTEM=linux-gnu-eabi
> DEB_HOST_GNU_TYPE=arm-linux-gnu-eabi
Actually EABI compiler reports arm-none-linux-gnueabi, so
the last ones should be:
> DEB_HOST_GNU_SYSTEM=linux-gnueabi
> DEB_HOST_GNU_TYPE=arm-linux-gnueabi
Reply to: