Re: cross-compiling Debian packages
> +++ email@example.com [06-03-16 14:56 +0100]:
>> > managable as long as you stick with autoconf -based software, but
>> > you'll go nuts with the more esoteric build systems, like the one of
>> > apache. Even with autoconfed apps, things like gtk and pango are not
>> > easy to crosscompile.
>> The fact that they do not cross-compile cleanly is a sign that they
>> are written using wrong assumptions, such as CC=gcc or
>> -lc=libc.so.6. Should we not try to fix this at the source, i.e. in
>> the packages themselves? This would help BTW not only in
>> cross-compiling but also when the toolchains is upgraded.
> In general yes. I think it would be really valuable to fix all such
> problems at source. But there is a lot of stuff which doesn't cross
> compile due to test-programs built and run at build-time and tests which
> need to be run on the target not the buildhost. I don't think you can fix
> this for everything without deciding a 'debian way' to resolve these
> problems. (e.g building build-arch test, not target-arch test, vs. running
> target-arch test under emulation - I think you have to pick one or the
> other?) For build-time file-based tests, are we going to have a 'staging'
> area like OE to run target tests against, or some other mechanism?
> (dpkg-cross env vars)).
I once thought that we could maintain a database of configure variables that
are used in debian packages, with proper values for all target archs we are
interested in. This could work if organized properly (with auto-discovery
of new variables, auto-checking on available hardware when possible,
auto-notifying interested people when autochecking is not possible, etc).