See bug #201913 No justification was given for these packages being in Core instead of Extras, and none can be guessed. They should be moved to Extras.
+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