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. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part