Hi Neil, Thanks for taking the time to respond.
On Sat, Jan 03, 2015 at 06:31:38PM +0000, Neil Williams wrote: > > You are missing an important aspect here: dpkg-cross is currently the > > only way to build a cross compiler from src:gcc-4.9. > > Sorry, I did not miss that aspect: your statement is incorrect. I see that there is need for differentiation here. The statement is indeed too broad, but there still is some truth in it. > Clean pbuilder sid chroot: > > # dpkg --add-architecture armhf > # apt-get -qq update > # apt-get build-dep cross-gcc-4.9-armhf > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following NEW packages will be installed: > autoconf autoconf2.64 autogen autotools-dev > binutils-arm-linux-gnueabihf bison bsdmainutils chrpath cross-gcc-dev > debhelper diffstat expect file flex gawk gcc-4.9-base:armhf > gcc-4.9-source gdb gettext gettext-base groff-base guile-2.0-libs > intltool-debian libasprintf0c2 libbison-dev libc6:armhf libc6-dev:armhf > libcloog-isl-dev libcroco3 libexpat1 libffi6 libfl-dev libgc1c2 > libgcc1:armhf libglib2.0-0 libgmp-dev libisl-dev libltdl7 libmagic1 > libmpc-dev libmpfr-dev libopts25 libopts25-dev libpipeline1 > libpython-stdlib libpython2.7 libpython2.7-minimal libpython2.7-stdlib > libsigsegv2 libssl1.0.0 libtcl8.6 libtool libunistring0 libxml2 > linux-libc-dev:armhf m4 man-db mime-support netbase patchutils > po-debconf python python-minimal python2.7 python2.7-minimal quilt > realpath sharutils systemtap-sdt-dev tcl-expect zip zlib1g-dev > > dpkg-cross is not mentioned in that list. Not only is it not the only > way to build a cross compiler from src:gcc-4.9, it is not even the > default way to build a cross-compiler from src:gcc-4.9. What is in the list though is cross-gcc-dev, which is a heavy patch pile. This is nowhere close to be the default for building cross compilers from src:gcc-4.9. In fact, it is so non-default that the gcc maintainer seeks to remove these packages: #771070. > Nothing about > building a cross-compiler or using a cross-compiler on Debian unstable > has to have anything at all to do with dpkg-cross - except that > some packages need data from those config files. Even that can be > patched in locally if someone has need. Such steps are a lot less work > than has been required to get packages to cross-build previously. Ironically, I have to agree here: Nothing about building a cross compiler needs dpkg-cross. What you do need dpkg-cross for however is satisfying the Build-Depends of src:gcc-4.9. After setting a target and regenerating debian/control, it does build-depend on e.g. libc6-dev-armhf-cross which is nowhere to be found and only obtained by running libc6-dev:armhf through dpkg-cross. So actually, you need dpkg-cross before building a cross compiler unless you apply heavy patches. Also note that the heavy-patching method of building a cross compiler has some drawbacks at the moment: * bootstrapping does not work. #774010 (patch available) * Various multilib issues. For powerpc I managed to understand one #774356, but other architectures still fail. * Current buildds do not run a version of sbuild that is capable of building e.g. cross-gcc-4.9-armhf. (jessie sbuild is fixed) * britney cannot migrate these packages due to cross-arch dependencies. (Wookey is working on a solution.) None of the above applies to the supported method (which involves dpkg-cross). > 2: the problems of cross-building on jessie have been well known since > the wheezy release and all the work went into trying to get the correct > methods working. It is funny that you paint the heavy patching method as "correct" while there is bitter disagreement about which method actually is to be used. > My personal feeling is that dpkg-cross never deserved to be in the main > archive - it should have stayed in the Emdebian toolchain repositories > - but I was not involved in dpkg-cross at that time, I had to work with > it where was. As I've already said, it was never possible for > dpkg-cross to be Policy compliant. It is designed to break Policy. The > irony is that it will finally be removed from testing for doing > explicitly what it was designed to do. That is fine by me, I wanted it > gone a long time ago. I think that there is quite a big difference between a package that does not comply with the policy and a tool that produces non-compliant packages. I acknowledge that dpkg-cross produces non-compliant packages and always did so. However, users have the general expectation that packages in the archive adhere to the policy no matter what they are useful for and we should keep up that promise. In a similar vein, we do not expect packages generated by equivs to adhere to the policy, but we do expect equivs itself to comply. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
