Re: Deciding new arm EABI port name
Riku Voipio wrote:
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..
Yes, please, make this as simple as arm-eabi.
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.
Sure.
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.
*small* performance problems manifest themselves *big* way on *smaller*
systems.
When you have to fit a distribution in 16 megs, even 5% counts...
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..
Just finished compiling mplayer & friends (quite some packages) for
arm and arm-softfloat. Works fine...
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
Looking at Sourcery's FAQ, they've chosen gnueabi because of
unwillingness to
patch tools to support CPU-VENDOR-LIBC-ABI scheme. This looks quite ugly
to me,
to depend (again) on broken/dump tooling in favor of clarity.
Reply to: