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

Re: dpkg armhf patch acceptance status?



Hi!

[ I'm leaving for two days, and running out the door just right now, so
  this mail is a bit rushed, and might contain inaccuracies and
  repetition due to lack of proper review, sorry about that, I'll try
  to clarify anything unclear once I get back. ]

On Tue, 2010-09-07 at 14:01:37 +0300, Konstantinos Margaritis wrote:
>   I really would like to know the stance of the dpkg maintainers regarding the 
> armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as 
> bug reports, but without the dpkg patch, those patches would be useless, so 
> I'm holding back, but that in the meantime increases the workload as newer 
> packages appear all the time and I have to forward port the armhf patches all 
> the time. Plus, the whole port is unusable without dpkg functioning properly. 
> The patched version I have uploaded in debian-ports works fine without any 
> side-effects whatsoeer. I'm not asking for immediate acceptance, but even a 
> short mail of 'it's ok, but needs more work here and there' will do. 

I don't quite like the current implementation, which abuses the vendor
for information related to the ABI.

So, recapping a bit the long thread about the new port:


I agree with Paul Brook that abusing the vendor in this way poses a
compatibility issue with upstreams, I'd rather not use something like
this which is probably Debian specific.


We currently need something like this in dpkg-dev because the mappings
need to be bidirectional, as dpkg-dev needs to be able to convert
from GNU triplet to Debian architecture and the other way around.

Steve wondered why this is the case, and that's because for
cross-compiling purposes dpkg-architecture infers the host architecture
from the CC environment variable through the -dumpmachine option.
Chaning this is possible but, would break a current way of
cross-compiling which has been around for a long time.


The toolchain has the same triplet for binary incompatible producing
objects, which seems like a bug/misfeature to me, and that's one of
the assumptions dpkg-dev has relied on, in the same way as multiarch
when deciding to use the triplet as a unique token for the installation
directories. Although one can produce binary incompatible output with
normal gcc options, like changing the calling conventions with something
like for example -fpcc-struct-return, but those are not part of the
default ABI, and are expected and warned as producing incompatible
binaries.

This also causes issue with not being able to have installed two
cross-toolchains for say armel and armhf as they share triplet,
although you can use the armel toolchain with few options to build for
armhf, but then you'd need to specify those as part of the CC variable.
Also that also happens with biarch, you can produce i386 binaries from
an x86_64 toolchain, yet they both have their own triplet.

I'm just wondering if this is also the case for mips triarch, or do
those have each their own triplet, and is only arm that has this
issue?

Anyway, ideally I'd rather see this addressed by giving armhf a real
triplet, which would also make multiarch life way easier as there'd not
be any need to define an artificial set of neutral architecture names
to be able to place objects in the file system. But if this is not going
to happen, and thus the assumptions dpkg-dev is making have been just
wrong, then I'd rather drop the bidirectional mappings, and be done
with it. This will need careful consideration though, as it's breaking
a current interface, but something that could be done for dpkg 1.16.x.


I can propose a patch for this once I get back.


thanks,
guillem


Reply to: