Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

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

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.

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.

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgphZuNQD8041.pgp
Description: PGP signature