Control: forcemerge 644664 -1
[ More of a brain dump than anything else. ]
Hi,
On Thu, 2018-04-05 at 17:46:18 +0200, Helmut Grohne wrote:
> Package: dpkg-dev
> On Thu, Apr 05, 2018 at 04:28:48PM +0200, to...@tuxteam.de wrote:
> > - Need to set CC
> >
> > Yes, the warning was clear enough, but I was a bit surprised
> > I had to set CC like so:
>
> The warning you are talking about likely is this one:
>
> | dpkg-architecture: warning: specified GNU system type $DEB_HOST_GNU_TYPE
> does not match CC system type $DEB_BUILD_GNU_TYPE, try setting a correct CC
> environment variable
>
> I think this warning is obsolete as we assume that the packaging sets up
> CC. For most cases, it actually happens automatically:
> * dh_auto_build passes it to make.
> * If you include /usr/share/dpkg/buildtools.mk in debian/rules, it'll
> be correct.
> * For many build systems, setting CC is not necessary and
> dh_auto_configure does the right thing anyway.
>
> Telling the builder to set up CC is not needed at all, at least for 2000
> source packages and most of the failing ones don't fail due to missing
> CC.
>
> Heck in many cases, I've seen and introduced workarounds like "CC=true
> dpkg-architecture ..." to make it stop being noisy.
>
> Guillem, can we just remove the warning?
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.
2) perform some kind of consistency and sanity check, to make
sure the compiler architecture matches the one requested.
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.
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.
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.
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.
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.
Thanks,
Guillem
