On Thu, 18 Apr 2013 16:41:35 +0200 Matthias Klose <doko@debian.org> wrote: > - running a gdb:amd64 on i386 to debug 64bit binaries. This is the > reason for our current gdb64 package on i386, but it is missing the > support for the python based pretty printer. > Installing gdb:amd64 on i386 in wheezy will remove the whole i386 > python stack and then install the amd64 python stack. For this use > case the needed amd64 python stuff should just be installed without > removing the i386 packages. > > - install vim for a foreign architecture. Ok, not really a good use case, > but it comes with an insane amount of embedded interpreters. It > should be installable without removing the "native" interpreter > packages, and the embedded interpreters should still be usable. Hmm, is this really a strong use case? vim-tiny can be a pain sometimes, I know, but are those embedded interpreters in vim-full all that useful? (Or am I missing something?) > - Third party modules for interpreters should be cross-buildable. > Many build systems for interpreter languages are written in the > interpreter language itself. So you do require the interpreter > for the build, and the development files for the host. To me, that is a traditional cross-build relationship, it doesn't require the installation of runtime files for the interpreter for the foreign architecture, only the native runtime and the foreign development files to support those third party modules which are architecture-dependent or have architecture-dependent build dependencies. I don't see a need to have the perl:i386 interpreter installed on amd64 in order to build third party i386 perl modules, the amd64 interpreter should be fine, just as it is when cross building third party armel perl modules. > When trying to build a base system, you meet build dependencies > on interpreters very early. You can either work around these > by staged builds, or provide an interpreter which supports cross > builds for third party packages. However most interpreters require > some work to cross-build, and you have to figure out how to cross > build the extensions. Staged builds will still be needed for bootstrapping to sort out build-dependencies on things like documentation-build tools used by packages which need to be built quite early in the process. However, if the need for staged builds can be reduced somewhat by better support for interpreters and the tools which use them, that's good. I'm just not sure it provides that for the typical cross build use cases. I don't see the link between cross-building and this special-architecture pair relationship. After all, it is rare that someone needs to cross build packages for armhf on an armel machine and the reverse is just a chroot. Building i386 on amd64 is similar, just use debootstrap. I've seen just an individual enquiry about building amd64 on i386 but that is getting very specialised. Much more likely to be an amd64 or i386 buildd preparing packages for armhf where this support won't matter. The "typical" use case for cross-building is to speed up the build or build where no tools yet exist and will therefore remain with the installation of development files for the foreign architecture rather than runtime files. > So the gdb/vim use cases would require co-installation of the runtime files for > more than one architecture (including in most cases the shared library, some > standard libraries, or subset of these), and keeping the interpreter for the > default architecture. I agree that this is limited to the gdb/vim use cases. > The cross build case would require in addition co-installed development > packages, provided that these can be used for a cross-build. The cross-build use case would require the co-installed development packages but I don't see a need for foreign runtime files. Interpreters (except special cases inside their own builds) should isolate the third party modules from the architecture of the interpreter itself. Bugs in that support need to be fixed in the interpreter, not the distro or toolchain. > So what is the status for some runtimes/interpreters (would like to see some > follow-up/corrections from package maintainers)? > > - OpenJDK: runtime and development files are co-installable, the > package itself is not cross-buildable, and afaik nobody did try > to cross build any bindings. > > - Perl: Afaik, Neil did prepare the interpreter to cross-build, and > to co-install the runtime and development files. What about > cross-building third party modules? As far as bootstrapping is concerned, the only third party perl modules which are an issue are those which have architecture-dependent build-dependencies (bindings for arch-dependent libraries etc.) but there aren't that many of those which are also essential to getting a new port to the point where there is sufficient perl support to start building packages natively. Yes, there are a number of those inside the main perl packages and there is ongoing work with upstream to handle those properly, but only a subset of architecture-dependent third party modules are involved in bootstrapping. Certainly when I last did a full cross-build for Emdebian Crush (based on Lenny), I didn't have particular problems cross-building third party perl modules. HTH -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpTlNGrBF0oJ.pgp
Description: PGP signature