On Mon, 2008-03-17 at 12:17 +1100, Brendan Simon wrote:
Should it be possible to install cross-compiler tools and libraries from
an emdebian testing repository, to a debian testing i386 host, without
having to build from sources ???
Possible? yes, most of the time.
Assured? No - and this is not going to change before Lenny.
It's not even possible to require that the relevant packages can even be
built from sources because the kind of builds that we need do not
qualify for release-critical FTBFS bugs, only wishlist.
If you think that should change, please help us persuade more people
within Debian that crossbuilding and cross toolchains are sufficiently
important that support should be assured. The ultimate goal of getting
crossbuilding issues to be release-critical is a much more difficult
aim.
Before we can even push that objective, we need to solve the problems
here and now, workaround the issues, wait for updates and fixes and try
to produce something that other people in Debian can see as worthwhile
compared to further delays to Debian releases.
I just need gcc-4.1 or gcc-4.2 to cross build for a powerpc target for now.
I'm happy to keep working on trying to get gcc-4.3 going in unstable,
but I figure the problems may take "me" quite a while to understand and
resolve.
From the error messages I see with emchain (without --force) it seems
to suggest that some of the gcc-4.3 dependencies are not working on
native powerpc hosts, and therefore unlikely to cross-compile correctly
either. Is that the case ???
Yes. You can see for yourself:
http://packages.qa.debian.org/g/gcc-4.3.html
gcc-4.3 is out of date on arm and powerpc (and lots of other
architectures).
That is a Debian problem and *can* signify that the package simply
cannot be built on that architecture so emchain complains. (emchain is
unable to determine the cause of the failure automatically.)
There is no point trying to build a cross building toolchain when:
1. Emdebian normally builds it but hasn't got one already and
2. Debian hasn't built the relevant packages natively yet.
emchain is only for use when Emdebian does not already provide the
relevant toolchain and if the toolchain is question is normally built by
Emdebian, the failure is likely to be because the packages simply won't
build.
You seem to be thinking that Emdebian can provide something we cannot.
Crossbuilding and cross toolchains are *NOT* important to Debian in
general. Whether a particular package cross builds is largely irrelevant
to the rest of Debian - which is why all crossbuilding bugs are
wishlist, even complete failures to crossbuild.
So in the absence of any assurance that the new version can be cross
built (or built as part of a toolchain), emchain tries to stop you
wasting your time on a package that simply cannot be built the way
you/we need to build it. This may seem important to you and I but it is
simply not a priority for Debian.
Summary:
1. We need customised builds of Debian packages whereas Debian only
requires that the native build is sane. Not enough Debian people care
about the kinds of builds that we need.
2. Each Debian upload causes a period of time where the latest version
is out of date on one architecture or another. Sometimes this is just a
couple of days for the buildd network and mirrors to update. Sometimes
this is a packaging problem and a new upload is needed before the
package can be built in Debian (i.e. an RC FTBFS bug). Sometimes this is
just a crossbuild problem and the relevant package will migrate into
testing still 'broken' because a failure to cross build or failure to
build as part of a crossbuilding toolchain is not sufficiently important
to delay migration into testing. (If it was, almost nothing would ever
get into testing.)
3. These are difficult problems without available solutions and without
any particular drive within Debian to implement those solutions because
there is a perception that what we need is not important to the majority
of Debian users or Debian implementations.
4. Fixing these issues is a difficult and long standing problem that is
unlikely to be fixed soon. Therefore, we spend time working around the
issues so that we have something to show people when we try to persuade
them of the value of cross building but the time spent devising the
workarounds and the inherent delays caused by the above problems only
delays the overall solution.
There is no point hoping that this will get better on its own. Debian
needs to be persuaded that what we need can be a priority within Debian
itself and to do that, we need to first find solutions to all these
problems and come up with something that shows Debian what could be done
if the systems within Debian were modified to ease our workload.
So far, we have a set toolchains (incomplete), a set of root filesystems
for ARM which boot on only one particular device and a set of prebuilt
packages (for ARM only) as well as a variety of tools and systems that
support these implementations.
The toolchains will remain incomplete because each update in Debian can
cause breakage in the toolchain builds and the lack of a crossbuilding
autobuilder means that the relevant maintainers cannot test for
compatibility with our needs prior to an upload into Debian.
The root filesystem support needs more developers to broaden the
architecture support and device support.
The infrastructure needs continuing development to support more
automation to reduce the overall workload, including autobuilders for
the toolchains and the target packages.
emdebian-tools does what it can but a lot of these issues are way
outside the scope of such scripts.