Re: Proper way to initiate cross-building of a package
Hi Helmut. Thanks for taking the time to reply.
Helmut Grohne <helmut@subdivi.de> writes:
> 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.
I haven't run any large-scale experiments, and I'm certain you have a
much better idea here than I. My goal here was to cross-build some of my
own packages that use plain Make internally with the default CC.
>> 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).
This is explicitly my use case, and it does work.
> 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!
Just tried perl. No surprises; there are deeper issues here.
>> 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.
Again, default make variables do not override the environment variables;
maybe we're talking about something different. Invoking 'CC=whatever
make' does have the desired effect on the build.
> 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.
Sure, there are many things one can do once one accepts that explicit
porting work is necessary for each package. The hope here was that many
packages could be supported by a change in the tooling.
Reply to: