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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CADf0C44cgaEXLz213p9Q+c=34fB0Cm6M6mpMOar7vP6=yYe7L Q@mail.gmail.com

On 17.08.2012 18:12, Daniel Schepler wrote:
> 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.

well, then try to disable the Debian patches until you find an offending patch.

> 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.

look at the genmultilib output and at the gcc -print-multlib output.

> On a side note, instead of adding libx32gcc1 etc.,

I don't like the idea of having to cros-build-depend on other architectures, so
as a first step, I'd like to see these packages built.

do your patches work to build a triarch compiler on amd64/i386?

Matthias


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50322F63.2070301@debian.org">http://lists.debian.org/50322F63.2070301@debian.org

OK, I've gotten it working now. The issue was that I hadn't added x32
to biarch64 or biarch32, so biarch_multidir_names was never being set.
(I also added x32 to the multilib dirs that get filtered in
ml-config.diff, since that's what pointed me to the problem.)

On Mon, Aug 20, 2012 at 5:36 AM, Matthias Klose <doko@debian.org> wrote:
> On 17.08.2012 18:12, Daniel Schepler wrote:
>> On a side note, instead of adding libx32gcc1 etc.,
>
> I don't like the idea of having to cros-build-depend on other architectures, so
> as a first step, I'd like to see these packages built.

Neither do I -- but I also don't like the idea of [e]glibc having to
keep cross-building libraries purely for the use of gcc builds. And
IMO all other Debian package uses of gcc-multilib and libc6-dev-*
should go away during the next release cycle in favor of multiarch (at
least I can't think of anything else where it's justified). But
again, discussion on these issues can wait until the upcoming release
is out.

> do your patches work to build a triarch compiler on amd64/i386?

Not yet, now that multilib is actually building I can start working on
the actual packaging changes.
--
Daniel Schepler


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CADf0C47KYJnORUxAaUVBSmo84i8q9rNN13TpV1T1PkkJDS7N8 Q@mail.gmail.com">http://lists.debian.org/CADf0C47KYJnORUxAaUVBSmo84i8q9rNN13TpV1T1PkkJDS7N8 Q@mail.gmail.com

On 21.08.2012 06:51, Daniel Schepler wrote:
> OK, I've gotten it working now. The issue was that I hadn't added x32
> to biarch64 or biarch32, so biarch_multidir_names was never being set.
> (I also added x32 to the multilib dirs that get filtered in
> ml-config.diff, since that's what pointed me to the problem.)
>
> On Mon, Aug 20, 2012 at 5:36 AM, Matthias Klose <doko@debian.org> wrote:
>> On 17.08.2012 18:12, Daniel Schepler wrote:
>>> On a side note, instead of adding libx32gcc1 etc.,
>>
>> I don't like the idea of having to cros-build-depend on other architectures, so
>> as a first step, I'd like to see these packages built.
>
> Neither do I -- but I also don't like the idea of [e]glibc having to
> keep cross-building libraries purely for the use of gcc builds.

No. the multilib configurations are used for more than that. No, not for package
builds.

> And IMO all other Debian package uses of gcc-multilib and libc6-dev-*
> should go away during the next release cycle in favor of multiarch (at
> least I can't think of anything else where it's justified).

No. They should stay, to build a multilib'ed compiler. And I won't apply any
local patch to the gcc package to lookup header and o files in other places, so
if you want to improve the situation, work with upstream to get this into the
next GCC release.

Matthias


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50336770.8040707@debian.org">http://lists.debian.org/50336770.8040707@debian.org

On Tue, Aug 21, 2012 at 3:48 AM, Matthias Klose <doko@debian.org> wrote:
> No. They should stay, to build a multilib'ed compiler. And I won't apply any
> local patch to the gcc package to lookup header and o files in other places, so
> if you want to improve the situation, work with upstream to get this into the
> next GCC release.

I'm not sure what you're trying to say here. I didn't have to change
any search paths to get this to work, beyond updating the multiarch
patches for x32.

I've gotten the x32 triarch packages working, and uploaded to
http://people.debian.org/~schepler/gcc-4.7-x32/ -- along with
debdiff.diff, and packages.txt which contains the output of dpkg-deb
-I and dpkg-deb -c for each package. Hopefully this will give a more
concrete idea of what I'm trying to do.

I'm unable to properly install gcc-multilib and g++-multilib yet, due
to version mismatches in libgcc1, libgomp1, etc. But if I force
install the packages and mismatching versions of their dependencies,
it works successfully to build and run a small test C++ program in all
three modes.

Disclaimers: this is just a prototype, with more hard coding than I'd
like; and I've probably broken non-amd64/i386/x32 architectures with
it. I'm also pretty sure I've missed most places where I'd need to
add x32 multilib support, so it will need more work before it will
build properly on amd64 or i386.
--
Daniel Schepler


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CADf0C44oe74YM7nY2K2edV4Yv1JExf7N2n-EojTcKxoGCw9MKw@mail.gmail.com">http://lists.debian.org/CADf0C44oe74YM7nY2K2edV4Yv1JExf7N2n-EojTcKxoGCw9MKw@mail.gmail.com

I've finally gotten the tri-arch compilers building on all three
architectures, and updated
http://people.debian.org/~schepler/gcc-4.7-x32/ with the resulting
packages.

Let me take one more shot at convincing you of migrating the
*-multilib and source packages to using multiarch (after wheezy
releases, of course): With the current situation, anyone who needs
both multiarch libraries and gcc-multilib will necessarily end up with
two copies of 32-bit [e]glibc on their system, libc6-i386 and
libc6:i386. That seems like needless duplication in a fairly common
situation.
--
Daniel Schepler


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CADf0C47w-87mKThVcUKuoSGf_sVGZNZEXRSti5vCTkR8gFj0OA@mail.gma il.com">http://lists.debian.org/CADf0C47w-87mKThVcUKuoSGf_sVGZNZEXRSti5vCTkR8gFj0OA@mail.gma il.com

On 27.08.2012 17:16, Daniel Schepler wrote:
> I've finally gotten the tri-arch compilers building on all three
> architectures, and updated
> http://people.debian.org/~schepler/gcc-4.7-x32/ with the resulting
> packages.
>
> Let me take one more shot at convincing you of migrating the
> *-multilib and source packages to using multiarch (after wheezy
> releases, of course): With the current situation, anyone who needs
> both multiarch libraries and gcc-multilib will necessarily end up with
> two copies of 32-bit [e]glibc on their system, libc6-i386 and
> libc6:i386. That seems like needless duplication in a fairly common
> situation.

there is a lot more duplication in GCC packaging, like building various
front-ends from separate source packages, which does help other things like less
complex package migrations. So duplicating things isn't that bad.

Having dependencies on non-default arch packages means that these have to be
available in the very same version, or else you won't be able to install or
upgrade. This is the kind of thing I do not want to see.

So there should be always a way to build and install a gcc-multilib without any
non-default arch packages. So if you want to work on this, then please make the
dependencies look like 'lib32gcc1 | libgcc1:i386' and make sure that the 32 and
64 bit packages are built on x32 too.

And somebody who installs gcc-multilib usually doesn't care about the extra files.

Matthias


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 503C819F.1060902@debian.org">http://lists.debian.org/503C819F.1060902@debian.org

On Tue, Aug 28, 2012 at 1:30 AM, Matthias Klose <doko@debian.org> wrote:
> So there should be always a way to build and install a gcc-multilib without any
> non-default arch packages. So if you want to work on this, then please make the
> dependencies look like 'lib32gcc1 | libgcc1:i386' and make sure that the 32 and
> 64 bit packages are built on x32 too.

I'm not sure I'd want to add all the complexity of an alternatives
system or something similar, which would be needed to make sure the
symlinks in /usr/lib/gcc always point to an appropriate library no
matter which package is installed. So I guess I'll just start working
on adding libc6-x32 and libx32gcc1 packages to the existing structure.
--
Daniel Schepler


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CADf0C45jGq1YHdbK6_keZxEvo7zJkXSON=2a=c1LVJQ3KC5ju g@mail.gmail.com