Re: Proper way to initiate cross-building of a package
On Wed, Aug 05, 2015 at 05:11:23PM -0700, Dima Kogan wrote:
> Instead of that command, one could instead issue
>
> dpkg-buildpackage -aarmhf
>
> This type of invocation works for dpkg-buildpackage and sbuild, but I
> find that the compiler variables (CC and such) then don't get set
> automatically, and the build fails, unless the debian/rules explicitly
> handles cross-building.
Do you have a gauge on how frequent that problem is? I recently
crossed[1] 1k packages and about half of them worked without setting CC.
Clearly, there are some that would have succeeded when setting CC, but
this is a fraction of the failures. In particular, autotools projects
don't need CC at all.
> First of all, this latter invocation is the "correct" one, yes? If so,
> then I think it'd be great if the compiler variables were set without
> explicit support in debian/rules. Most packages use debhelper, so that
Given the data above, I argue that setting CC is not required.
> seems like a logical place to put that. I implemented a very simple
> change to debhelper that does this:
>
> http://anonscm.debian.org/cgit/users/dkogan-guest/experimental/debhelper.git/commit/?h=auto_cross_cc&id=f58f39dacb46759fa8c02eb7fa5cebe0a9dcc955
>
> Here whenever we look at 'dpkg-buildflags' to set the compiler flags we
> ALSO set the compiler variables if (we are cross building AND these
> variables aren't yet set). This patch works for trivial debhelper-based
> debian/rules, which look like this:
>
> -----------------------
> %:
> dh $@
> -----------------------
This claim is not really true. Depending on the actual build system,
different things happen:
autoconf: Setting CC is not necessary, because we already pass --build
and --host. Setting CC shouldn't make a difference in most cases.
cmake: Not sure what happens, but I think the correct solution is #794396.
makefile: If the underlying project actually uses CC, then most likely
it is using the make variable CC, which defaults to cc despite
setting the environment. Thus your proposed change is ineffective.
Rather one would have to pass CC=... as an additional argument to
make (like DESTDIR).
ant/perl_*/py*/qmake: Not sure what happens here, but I'd be surprised
if crossing works with any of these at all. Please surprise me!
Thus the cases where exporting CC might help are mostly those that are
not using dh.
> This patch touches CC and CXX only, and would need to be expanded to
> cover more of the tools. Is this a reasonable way to go? Looking around,
> it isn't obvious what the concrete plan is and how this should be
> handled otherwise. Not requiring every package to put stuff into their
> debian/rules to support cross-building is desirable, and that's the main
> advantage that I see of putting this logic here.
On the contrary, I think this change is actively harmful. It might lead
developers into thinking they can use CC when using dh. But due to the
nature of default make variables overriding environment variables, you
don't actually get the desired CC value. For safe usage of CC, one still
has to set it explicitly.
A different approach to solve the same problem was proposed by Guillem
Jover[2]. It involves adding a /usr/share/dpkg/buildtools.mk to
dpkg-dev, which can then be included in debian/rules.
The counterpart to this proposal is to extend individual debhelper
buildsystems to work better for crossing. #794396 is a step in that
direction.
I hope this makes sense.
Helmut
[1] Or rather debomatic. Thanks to Luca Falavigna.
[2] http://lists.debian.org/20150510013227.GA24314@gaara.hadrons.org
Reply to: