Bugzilla Bug 29952

Patches to gcc to allow multilib support so both 32bit and 64bit binaries can
be compiled on the same system, with the same compiler.
Requires:
  * gcc-config patch
  * binutils patch
  * emul-i686 ebuild

Created an attachment (id=18503) [details]
put patch in files/ directory. multilib patch.

Created an attachment (id=18504) [details]
patch for gcc-3.3.1-r3 ebuild

Created an attachment (id=18514) [details]
gcc-3.3.1-r3.ebuild patch  make use of 'multilib' use flag.  Only builds
multilib if in use flags.

Checks for both ARCH=amd64 and `use multilib`.
If both of those are true, it will build gcc with multilib support.
It also adds a hard dependancy on sys-libs/emul-i686 so you need that
installed to compile multilib support.
By default, it does not build multilib.

I request that this patch be added to CVS, along with the other
dependancies.  None of the changes have an adverse affect on anything
else, and just add a more robust feature-set to gentoo on amd64.

I think the idea was to have 32bit stuff in a chroot, so this needs some
discussion from the involved parties

There's a discussion on it in Bug #29857 ...
Restricting everything to a chroot environment is extremely limiting.
You're talking about having a completely different version of GCC, and
all command line utils, etc.  Very, very wasteful, when this solution
can utilize the current system (while still maintaining the ability
to chroot if you desire). Basically, it adds no overhead.
Besides that, it's OPTIONAL ... enable USE 'multilib' or not, it's the call
of whoever is building that particular system.

I agree that we should have support for it for users who do want it.
Personally,
I don't do anything requiring 32-bit binaries, but I can see where a
significant
number of people would desire it. An off-by-default USE flag doesn't harm
anything.

Created an attachment (id=18571) [details]
gcc multilib path patch. put in  files/

relocate some paths

Created an attachment (id=18572) [details]
gcc 3.3.1-r3 ebuild patch

Last gcc patch borked C++ 64bit compiles.  This fixes that.  32bit C++ compiles
are borked for the moment, yet C compiles in 64bit and 32bit work fine. 
Got to
dig into the depths of GCC hell this weekend to figure out why 32bit C++
paths
passed to the linker are borked.  Will get it to work sanely though...

Created an attachment (id=18576) [details]
gcc multilib patch.  put in gcc  files/ directory

Created an attachment (id=18577) [details]
gcc multilib patch. put in gcc files/ directory

Created an attachment (id=18578) [details]
gcc 3.3.1-r3 ebuild patch

long day.
Finally realized that gcc and g++ won't honor what's in the
config for multilib, unless it's a relative path starting with ../
So it would never properly resolve crt1.o and friends for 32bit 
compiles but would for 64bit compiles.
Wish this crap was documented.	Anyhow, EVERYTHING works now,
somehow ;)

Created an attachment (id=19319) [details]
gcc 3.3.1-r3 ebuild patch

update to ebuild patch for app-emulation/emul-linux-x86-baselibs
instead of sys-libs/emul-i686

Created an attachment (id=19347) [details]
Failed Patch: 02_all_gcc33-ice-hack.patch.bz2!

emerge failed after applying gcc-3.3.1-r3.ebuild.amd64.patch

was not able to reproduce those problems.
Updated to gcc-3.3.1-r5.ebuild and committed the changes,
as there are many successful reports in #gentoo-amd64