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

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.


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

Actually EABI compiler reports arm-none-linux-gnueabi, so
the last ones should be:

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: