Re: dpkg: emdebian.org and other machines patched for armhf support
(resend: typo in the address field, this was send to 594179@bugs.debian.org
and linaro-dev@lists.linaro.org originally, please add those in the replies)
On Tuesday 07 December 2010 16:02:16 Hector Oron wrote:
> Hello,
>
> I am patching machines to support armhf, which it is almost at 90%
> built. I know you are very busy with squeeze release, but could you
> give a comment if the patch is wrong or right, as we are using it for
> patching machines? Why is it taking so long to include such
> architecture?
> Let me know if I can help you out doing a NMU if you do not have the
> time.
Nice timing Hector, I was just thinking of sending a mail to the lists (so I'm
cross-posting this mail to both debian-arm and linaro-dev lists as they are
[in]directly involved in this).
In essence, I would like to express my objection in having the same triplet
for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they
just haven't done the extensive compiling I have and didn't consider the
problems (I doubt anyone else has built ~8000 packages for a hardfloat port).
So, what is the problem: I'm trying to port some compilers now to armhf now -
gnat, openjdk, etc- using cross-compiling (you know, build a cross-compiler on
an arch that already supports gnat, then use that cross-compiler to build a
native binary and use that binary to build the final compiler on the native
machine. It's a complicated process with lots of problems, but I've done this
before -I actually did the gnat powerpc port for Debian back in 2000, using
that same method, things have evolved since then but not that much.
With a different triplet, I just have to add a new triplet entry for armhf to
gnat's setup scripts.
Using the same triplet, I would have to actually go to great lengths to change
the scripts to use something else than the gnu triplet to decide cpu/system
detection -not to mention that I would have to push for acceptance for each
and every such patch. I'm sorry, but right now I have better things to do than
this.
Anyway, I know this point has been stressed before, but I now I would like to
re-surface this issue again.
Till now I was mostly indifferent, but now I'm convinced that we should *not*
force the same triplets for the two abis until there is a concrete migration
plan of OS detection using another method. It mostly ends down to unnecessary
over-engineering with little benefit and way too many problems. I like
simplicity and any other solution than a single triplet is not simple at the
moment.
So, what does this mean? It means that someone has first to propose a proper
solution for handling this sort of stuff when a single triplet -something like
that has been proposed in http://bugs.debian.org/596298 but though it's a good
idea, it has not been discussed as much as it should. It has to actually be
decided and even then we still would have to change many configure scripts to
use that, as gcc for example configures based on the gnu triplet, NOT
something as arbitrary as DEB_{HOST,BUILD}_ABI. In real terms, this means it's
going to take a very long time to actually have something that works -no I
don't think 6 months are enough.
Anyway, with regards to the actual bug report, I have done a 1.15.8.6+armhf.1
release -in debian-ports.org/unreleased for now- which fixes a bug I missed
previously. Some tests also fail, but that's beside the point, they have to be
fixed to support quads as well -which I will do in the next days and I will
send a complete patch. For that matter, I have tested the patch on amd64 and
i386 and it doesn't break anything.
The problem is that with ~7600 packages built and still the port is not
recognized by dpkg.
So, bottom line, until the issue with multiarch/DEB_HOST_ABI is actually
*decided* could you please please get armhf support into dpkg proper? Or at
least give a good reason why you do not accept the patch?
Thanks
Konstantinos
Reply to: