Bug 204124

Summary:	No need for compat-gcc-34 to be in Core
Product:	[Fedora] Fedora	Reporter:	David Woodhouse <dwmw2>
Component:	compat-gcc-34	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	Christian.Iseli, cweyl, dennis, fedora, gajownik, jwboyer
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-01-01 12:40:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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