Re: Deciding new arm EABI port name
Riku Voipio wrote:
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)
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.
*small* performance problems manifest themselves *big* way on *smaller*
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
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...
Looking at Sourcery's FAQ, they've chosen gnueabi because of
patch tools to support CPU-VENDOR-LIBC-ABI scheme. This looks quite ugly
I would expect arm-eabi to look like this:
$ dpkg-architecture -aarm-eabi
Actually EABI compiler reports arm-none-linux-gnueabi, so
the last ones should be:
to depend (again) on broken/dump tooling in favor of clarity.