+1 for moving it to Extras

+1 for moving to Extras

I'm +1 still,  

But i have learnt that we would need to make some buildsys changes to support 
proper multilib building of gcc.

it seems  that core has a glibc32.x86_64 package that is installed in the 
x86_64 buildroot  but is not published. Not that its a justification for it 
being in core.  Just means we need to do some extra work  to make it build in 
extras.

(In reply to comment #3)
> it seems  that core has a glibc32.x86_64 package that is installed in the 
> x86_64 buildroot  but is not published. Not that its a justification for it 
> being in core.  Just means we need to do some extra work  to make it build in 
> extras.

And glibc64.ppc, of course, where the biarch stuff is done the other way round.

This is because libgcc_s.so.1 links against glibc, presumably. But there's no
real reason why we need to have the _real_ glibc, is there? Why can't we just
create a dummy DSO which contains the required symbols, and link libgcc against
that?

/me offended today by just how _much_ crap he had to extract into
/usr/i686-linux-gnu before he was able to build an i686-linux-gnu-gcc.

(In reply to comment #4)
> And glibc64.ppc, of course, where the biarch stuff is done the other way 
round.
> 
> This is because libgcc_s.so.1 links against glibc, presumably. But there's 
no
> real reason why we need to have the _real_ glibc, is there? Why can't we 
just
> create a dummy DSO which contains the required symbols, and link libgcc 
against
> that?
thats exactly what we will have to do.  I have to do it for sparc also so that 
i can build the compat-gcc packages.

I'm closing this; for FC6 it probably won't get fixed anymore (makes no sense)
and the problem will sort out itself in F7 and later in any case