Issues? ======= Making native tools look more like cross (doko) ----------------------------------------------- For building the kernel, clever upstream things often don't work with latest gcc so it build-depends on specific compiler versions. Need to add special cross-build setup to call the right cross-compiler. Build dependencies are different for native and cross-building. Would like a native compiler for (say) armhf and a cross-compiler targeting armhf to satisfy the same dependencies. Plan was for native compilers to also Provide the $triplet-$tool in the same way as the cross compilers, or add meta- packages for this, but not done yet. doko happy to do that, but hasn't seen recent patches from Helmut yet. Discussion about symlinks "Not going to make more binary packages than the Linux source" Help with general work (???) ---------------------------- Helmut looking for anyone else interested in *general* cross packaging work; most are only hacking on specific arches. Cross-building across kernel/libc (???) --------------------------------------- There have been requests for cross toolchains for hurd and kfreebsd too, but that will need changes around linux-headers/linux-libc-dev; current setup is very hard for non-linux non-glibc cross toolchains. They'd need to have stuff moved from /usr/include to m-a paths instead, which will increase the amount of duplication. Cross-build for other kernels is actually easy, but cross-build for other libc is much harder. How much effort should we spend? Maybe look at what xnox did for bionic cross-build as inspiration here, try and avoid too much change in the gcc/glibc packaging if we can dpkg-cross (codehelp/infinity) ------------------------------ codehelp would like to drop it, glibc is still using it for cross There's been no work in Debian for 2+ years. The idea was to try and just have config in dpkg-cross, but it's ended up owning far too many hacks and fixes to work around issues elsewhere, e.g. in autotools. Would be much better if it can just become a static configuration package. Current cross toolchain base packages basically contain copies of (some?) stuff in dpkg-cross package to try and avoid dependencies, but cross-build-essential still has a dependency anyway. That makes sense for configuration reasons. split into two packages: dpkg-cross binary and the cross-config stuff then later remove the horrid dpkg-cross binary. Remove existing maintainers from Uploaders list. codehelp's last action as maintainer is to drop debconf question for default_arch and do the split as a QA upload. Check for -dev packages which are for a different arch to the target and verify that those are installed for the target arch. cross-config or autotools-cross-config ? Test package cross-building in a buildd setup (zumbi) ----------------------------------------------------- Can we add a cross-buildd targeting something to help validate the cross-toolchains? Packages to test: every package x86 to armhf is probably easiest - run in testing suite. We expect many failures due to lack of upstream/Debian support for cross-build config, but can establish baseline and track packages which always fail vs packages which regressed. Dynamic loaders name clashes ---------------------------- Question about clashing ld.so filenames on various architectures. There's no good answer possible here.