Issues with trying to build Debian x32 gcc with multilib support
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
Reply to: