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