On Thu, Apr 12, 2018 at 01:18:57PM +0200, Guillem Jover wrote:
> So the intention here has been, AFAICT, to try to make detecting
> cross-building:
>
> 1) kind of automatic, something just needs to set CC to the correct
> cross-toolchain and then dpkg would figure out the host arch.
That must have predated my involvement. Ever since I worked on cross
building the canonical way to specify the host architecture has been
through dpkg-architecture -a$arch.
> 2) perform some kind of consistency and sanity check, to make
> sure the compiler architecture matches the one requested.
We don't even have widespread use of the CC variable. The clang people
essentially gave up on using it and simply divert gcc for their test
builds. Most of the working cross builds never set CC explicitly, but
the build system figures it out by other means (e.g. ./configure derives
it from $ac_tool_prefix, which comes from --host, which comes from
${DEB_HOST_GNU_TYPE}). In fact dpkg-architecture is happy with CC=true,
so any sanity check that is performed is not in fact sane.
> It is certainly true what you point out, and also that there are many
> other compilers, so the relationship between a C compiler and the
> resulting object installed might not match at all. Aslo even if dpkg
> itself set those envvars, there is no guarantee the debian/rules would
> use them. And I think the common way to request cross-compilation is
> via the dpkg-buildpackage -a argument nowadays.
>
> I guess given that cross-compilation has always been a bit rough on the
> edges, there's not been a clear direction how to expose cross-building
> interfaces until the above helpers gained support for it.
I must have been late to the party to the point where dpkg-architecture
has become the defacto interface.
> Removing the warning feels in a way like removing a safety check though,
> because while doing dpkg-buildpackage -afoo will emit it and it will
> be wrong, if the user specified an unmatched CC and -a, then bad
> things can happen. But if people cross-building have gotten used to
> ignore the warning anyway, then I'm not sure there's much point about
> it anyway.
There is no safety gained through this warning. It is emitted in the
common case, often worked around, it's like an annoying popup and the
user is trained to ignore it.
> If we'd go with removing the warning, I'd also have to question whether
> getting the architecture from CC or gcc is the correct thing to do, and
> whether we should instead expect the user to supply the arch, and
> simply validate that.
I don't think setting the architecture from CC is a good idea. If you
cross build with clang, you set "CC=clang -target
x86_64-unknown-linux-gnu". How do you parse it then?
> Something else that is related to this, and which I was pondering about
> and was kind of a blocker for fixing this or not, was whether to make
> dpkg-buildpackage set the buildtools variables itself, which would remove
> the warning altogether. This was tied in with the thread on d-d about
> the canonical entry point, and whether we'd still support debian/rules
> as that user entry point.
We have around 2000 source packages that build without dpkg setting it.
I don't see a compelling reason to change that interface. The present
way works. You can "dpkg-architecture -a$somearch -c ./debian/rules
binary-arch" and expect it to work.
> Another option, that might be more robust, would be to add some checks
> in dpkg somewhere, for whether the binary objects match the built
> arch (this is partially done in dpkg-shlibdeps, but I don't think it's
> complete or robust enough). This would of course trip over the abuse
> done by multilib packages where the contained objects do not match the
> .deb arch.
In practise, dh_strip performs that check. Quite a number of debhelper
packages just build for the build architecture and fail dh_strip, so we
already have this sanity check for the vast majority of packages. My
cross buildd performs the validation outside the build and rarely
catches a non-debhelper package.
To me, all of this sounds like we should just remove this warning
immediately with no replacement. It does no good, only harm.
Helmut
