it's about time we kill off these split packages and move to a common one (kgcc64) ive been using kgcc64 myself on powerpc and hppa and i know Kumba has been testing mips ... if you have any issues, please post them here
no feedback !? to be sure, i'd like to have these things out of the tree by 2006.2/2007.0 ...
(In reply to comment #1) > no feedback !? to be sure, i'd like to have these things out of the tree by > 2006.2/2007.0 ... > mips is fine here I've also been using it on sparc, and it works fine, except that weeve will probably still have his panties all bunched up because it doesn't provide "sparc64-linux-gcc" to satisfy the default kernel makefile (looks like it provides sparc64-linux-gnu-gcc instead). In fact, when I mentioned a problem I was having with kgcc64 at one point on sparc (turned out to be pebkac), weeve had no idea that such a thing existed, and was thoroughly astonished that it even had a ~sparc keyword. So perhaps you should poke the sparc guys a bit harder on this one...
(In reply to comment #0) > if you have any issues, please post them here I thought leaving no comment means 'no issues'. ;-) Anyway.. I haven't seen issues on ppc64 so far, though I'm not using 32bit userland that often.
i can have kgcc64 generate an $ARCH-linux-{gcc,cpp} wrapper as well ... i just thought that people wanted $ARCH-linux-gnu-{gcc,cpp}
(In reply to comment #4) > i can have kgcc64 generate an $ARCH-linux-{gcc,cpp} wrapper as well ... i just > thought that people wanted $ARCH-linux-gnu-{gcc,cpp} That $ARCH-linux-gnu-{gcc,cpp} would require a patch or sed to the kernel Makefile to work, in which case, you might as well stick with the default $ARCH-$MACHINE-linux-gnu-{gcc,cpp}.
So on sparc64, to satisfy either the upstream makefiles or the ones in any of our kernel ebuilds that support sparc64, we'll need a 'sparc64-linux-gcc' to exist. By default the makefiles check to see if gcc supports -m64, and if they don't, it looks for sparc64-linux-gcc. Since we don't support -m64, gcc-sparc64 provides the latter. I'd like to keep providing that going forward to maintain the current behavior.
done then ... kgcc64 no longer provides $arch-linux-gnu-gcc, just $arch-linux-gcc
I think we're pretty close on SPARC. Only obvious thing I see now is having to adjust the sys-kernel/linux-headers logic WRT the gcc64 use flag.
(In reply to comment #7) > done then ... kgcc64 no longer provides $arch-linux-gnu-gcc, just > $arch-linux-gcc And what provides $arch-linux-ld? /usr/src/linux $ make [...] CC init/do_mounts.o LD init/mounts.o /bin/sh: hppa64-linux-ld: command not found
that's a binutils issue, not a gcc issue hppa has "binutils-hppa64" because the hppa target does not yet support unified 32/64 bit hppa support
I presume this is only on those architectures which run mixed where the primary gcc is different then the gcc needed to build the kernel for whatever reason. If so, then ppc64 likely doesn't need to be on this bug as the user space compiler is the same as one would build the kernel with. However those that run on a ppc64 kernel but 32 bit user space might have an interest here *if* the gcc compiler isn't being built correctly with both 32/64 bit enabled. Further if there is some creation of say something like a powerpc64-linux-kgcc kind of thing, then really the ebuild on ppc64 would just need to create the symlinks and that'd be that. Feel free to drop by #gentoo-ppc64 to discuss. Thanks! Tom
this applies to every team that has their own "gcc-$ARCH" ... powerpc has "sys-devel/powerpc64" and it needs to go away
binutils-hppa64 fixed (thanks Spanky) kgcc64 marked stable on hppa moved gcc-hppa64 to kgcc64. will remove the old soon :)
poke poke ... if arches are OK with kgcc64, then feel free to finally make the move and scrub the old cruft
We've switched.
This is for ppc64 to decide, ppc32 should be fine with it, so I'm removing us from the CC list.
I just dropped gcc-hppa64 and moved it to kgcc64. Please re-add hppa if something is missing or else.
ppc64 done
