Bug 204124 - No need for compat-gcc-34 to be in Core
Summary: No need for compat-gcc-34 to be in Core
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: compat-gcc-34
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-25 18:31 UTC by David Woodhouse
Modified: 2007-11-30 22:11 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-01-01 12:40:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Woodhouse 2006-08-25 18:31:15 UTC
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.

Comment 1 Thorsten Leemhuis 2006-08-26 08:04:35 UTC
+1 for moving it to Extras

Comment 2 Josh Boyer 2006-08-26 13:52:11 UTC
+1 for moving to Extras

Comment 3 Dennis Gilmore 2006-08-26 19:59:56 UTC
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.

Comment 4 David Woodhouse 2006-08-26 22:56:17 UTC
(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.

Comment 5 Dennis Gilmore 2006-08-27 00:11:36 UTC
(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.


Comment 6 Thorsten Leemhuis 2007-01-01 12:40:03 UTC
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


Note You need to log in before you can comment on or make changes to this bug.