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

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 

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 

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 
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?



Reply to: