Bug 204124 - No need for compat-gcc-34 to be in Core
No need for compat-gcc-34 to be in Core
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: compat-gcc-34 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-25 14:31 EDT by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-01 07:40:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2006-08-25 14:31:15 EDT
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 04:04:35 EDT
+1 for moving it to Extras
Comment 2 Josh Boyer 2006-08-26 09:52:11 EDT
+1 for moving to Extras
Comment 3 Dennis Gilmore 2006-08-26 15:59:56 EDT
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 18:56:17 EDT
(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-26 20:11:36 EDT
(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 07:40:03 EST
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.