Public SourceMage Discussion List

[Ismael Luceno <ismael.luceno AT gmail.com>]

On Thu, 12 Jan 2012 10:49:45 +0900
flux <flux AT sourcemage.org> wrote:
> Ismael Luceno (ismael.luceno AT gmail.com) wrote [12.01.12 01:51]:
> > There's a problem when trying to bootstrap GCC with multilib
> > support. Looks like it requires 32bit glibc... (why in the
> > compiler!?). Am I correct or missed something? I think it's a bug
> > to not verify/rebuild libc, but I'm not sure how to handle it...
> > 
> > Also, I noticed /usr/include/gnu/stubs-32.h is missing. For building
> > applications sometimes it's useful to be able to produce object
> > files even if you can't link... so I think we should "fix" glibc to
> > install it anyway...
> 
> We officially do not support multilib. Multilib is a very broken and
> hackish solution to migrating from 32-bit to 64-bit, and has actually
> done more harm to migration than good (it's actually encouraged app
> maintainers to not bother updating their software to be able to build
> on 64-bit, or to not provide 64-bit binaries in the case of
> binary-only).
<...>

I know, but sometimes you just end needing it...

> 64-bit x86 is *NOT* the same architecture as 32-bit. Yes, there is
> backwards support, but the CPU goes into an entirely different state
> for this. If you want a 64-bit compiler that generates 32-bit output,
> you want a cross-compiler. So no, gcc should not be "fixed". Instead,
> you should either a) set up a 32-bit chroot environment with all
> 32-bit, or b) build a true cross-compiler toolchain in which the
> tools are built as 64-bit but all generate 32-bit.

OK, while I agree mostly, I must disagree about the toolchain. While
the CPU mode is different, the generated code is quite similar, so it
makes sense for the same toolchain to do both (and GCC handles it in
this way).

OTOH, what I question then, is why there is an option if it's
unsupported... shouldn't we remove it?

> People should really start thinking of 32-bit x86 and 64-bit x86 as
> being as similar to each other as MIPS-32 is to ARM 32-bit. It would
> help avoid confusions such as this.

The problem is that UNIX is broken, having a non-colliding naming
scheme is very desirable. Plus, the multilib spec is even more broken.

Yet sometimes we need all this heretic stuff...

Attachment: signature.asc
Description: PGP signature