I've been making some good progress with bootstrapping Debian x32 packages -- enough that I wanted to try adding -m64 and -m32 multilib support to the GCC package. Previously, I had been building fine without multilib configuration, just adding a patch to incorporate changes from git hjl/x32/gcc-4_7-branch, updating the multiarch patches to add x86_64-linux-gnux32 as the multiarch path for -mx32 mode, and adding "--with-abi=mx32" to the configure flags.
But when I add "--with-abi=mx32 --with-multilib-list=mx32,m64,m32" to the configure flags, that makes the compilation fail. What happens is that it never builds -m64 or -m32 versions of libgcc, so then of course the libgomp -m64 build fails. Exactly the same configure command works with plain hjl/x32/gcc-4_7-branch, or with hjl/x32/gcc-4_7-branch after a git merge origin/gcc-4_7-branch, if I create compatibility symlinks /usr/lib32 -> /usr/lib/i386-linux-gnu, etc. That leads me to believe the issue must be somewhere in the Debian patches. Any ideas where to look to see what could be causing this? As another data point, when I tried configuring instead with "--with-abi=m64 --with-multilib-list=m64,m32,mx32", it compiled -m64 and -mx32 versions of libgcc, but not -m32. On a side note, instead of adding libx32gcc1 etc., I'm also planning to make these packages a proof of concept on dropping lib32gcc1 et al and instead using multiarch. The basic approach would be to create e.g. an empty dependency package gcc-4.7-multilib-amd64 which is Architecture: amd64; Multi-Arch: foreign; Depends: libc6-dev, libgcc1, ..., libquadmath0, and similarly for g++-4.7-multilib-amd64. So then, for example, gcc-4.7-multilib on amd64 could Depends: gcc-4.7-multilib-i386, gcc-4.7-multilib-x32. I've already done the corresponding changes for my local glibc 2.16 packages, making libc6-i386 Architecture: i386, Multi-Arch: foreign, Depends: libc6, etc. Any comments on this approach? (I guess one issue is, depending on how apt actually behaves, we might need to keep libc6-i386 Architecture: amd64 and instead have it depend on libc6-i386-multiarch, Architecture: i386, Multi-Arch: foreign. And yes, this should definitely wait until the upcoming release goes out before doing anything more than local prototyping.) P.S. Just in case you're curious, my current stats on Debian x32 bootstrapping are: 12595 source packages successfully built, 666 failed, 4469 stuck waiting on failed packages, 55 built by hand to break dependency cycles, 71 built by hand to correct build failures (or in a couple cases, to correct run-time issues). The most common causes of x32-specific build failures (roughly from most common to less common): * Outdated libtool (which triggers runs of ld -m elf_i386 more than you'd otherwise expect due to glibc 2.16 also answering "undefined" to getconf ARG_MAX when there is no stack limit, causing max command line length to be set to empty with outdated libtool). * glibc 2.16 dropped exporting "gets" declaration by default, which steps on the toes of gnulib trying to attach a warning to gets. This is fixed in the latest versions of gnulib. * x32 port dropped support for sysctl(2). * Inline asm hard-coding *q size suffix when dealing with pointers. * time_t in x32 is 64-bit, which breaks assumptions of a few programs that sizeof(time_t) == sizeof(long). -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C44cgaEXLz213p9Q+c=34fB0Cm6M6mpMOar7vP6=yye...@mail.gmail.com