> And maybe Nikita could update the cross packaging bits? Hello. Seems that at last I've got something that works - at least it does the same that my patches for gcc-3.3 did. Patch (against gcc 3.4 source package downloaded 2 weeks ago from from http://people.debian.org/~doko/gcc-3.4/) is attached. Since 3.3, there are some upstream changes related to cross-compiler build. Upstream Makefile in gcc 3.4 uses $program_transform_name to append target-alias to tool names (e.g. to convert "gcc" to "arm-linux-gcc"). In gcc 3.3 this conversion was explicit. Currently, if either of --program-prefix, --program-suffix or --program-transfrom-name is passed to gcc 3.4's configure, it fails to set up proper $program_transform_name, and target-alias prefix is not added to tool names. I workarounded that by adding explicit --program-prefix to configure call from debian/rules2 Once I did that, I faced a bug in gcc's configure.in (propagated to configure) - it fails to handle properly situation when both --program-prefix and --program-suffix are given. The bug is trivial to fix, and is fixed in debian/patches/cross-configure.dpatch, but since configure is not recreated from configure.in during debian package build, I have to patch configure directly, which is definitly a bad idea. Another problem is that gcc 3.4's build system seems to assume that binutils are built together with (cross-)gcc, so same $program_transform_name is applied to "nm", "ar" and similar - instead of using autoconf-detected available tools. Of course "arm-linux-nm-3.4" is not available, so build fails. There is explicit code in configure.in (and configure) that overwrites detected tool names and replaces them with not working ones. So I fixed that also by disabling that code (after all, we are not gouing to build binutils together with gcc, are we?). This is second part of cross-configure.dpatch, and again it modifies configure directly, which is bad. After finding and fixing the above and making some technical changes in debian/rules* and debian/rules.d/*cross*, I was able to build cross-compiler and cross-library debs: libgcc1-arm-cross_3.4-0pre1_all.deb gcc-3.4-arm-linux_3.4-0pre1_i386.deb g++-3.4-arm-linux_3.4-0pre1_i386.deb libstdc++6-arm-cross_3.4-0pre1_all.deb libstdc++6-dev-arm-cross_3.4-0pre1_all.deb libstdc++6-dbg-arm-cross_3.4-0pre1_all.deb libstdc++6-pic-arm-cross_3.4-0pre1_all.deb Both arm-linux-gcc-3.4 and arm-linux-g++-3.4, installed on my x86 host (together with dpkg-cross'ed glibc), create valid binaries that work on my Ipaq. Several more notes: - There is a typo in debian/control related to move to non-epoched versions: gcc-3.4 depends on libgcc1 (>= 3.4), but it should depend on libgcc1 (>= 1:3.4) - libgcc1 version is still epoched. I've fixed this in debian/control.m4, but not in debian/control (later seems to be always re-created during package build). - The change in README.cross mentions a way to build cross-binutils from binutils package source, and is also appropriate to gcc-3.3 packages. - Installing both 3.3 and 3.4 cross compiler packages on the same host works; update-alternatives is used to manage target-alias-gcc and target-alias-g++ links. Priorities for alternatives are currently hardcoded in debian/gcc-cross.postinst both in gcc-3.3 and gcc-3.4 source packages. Currently, 3.3 is preferred by default. I hope to hear some feedback to know what to do next. Nikita
Attachment:
cross.diff.bz2
Description: BZip2 compressed data