Bug 53865
Summary: | Which gcc3 is on Rawhide? | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Need Real Name <ted> |
Component: | gcc3 | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-09-20 12:45:57 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
Need Real Name
2001-09-20 12:45:53 UTC
Yes, it is a patched CVS snapshot from 3.0 branch. It is called 3.0.1 because 3.0.2 was not released yet. 3.0 branch is in critical bugfixes only mode, so using the latest version from that branch is almost always a good idea (unless testing proves otherwise). Also the patches are needed, e.g. SHF_MERGE stuff which really saves space (be it in kernel or elsewhere) was only commited to CVS head since 3.0 was frozen, but we have tested this a lot (it is in 2.96-RH too). The number of patches against 3.0.x will grow, not shrink. OK I understand your point. Well, be cautious with the names of the directories (3.0.2) and the version of Gcc it refers too (3.0.1), it might cause some misunderstanding... Any problem compiling the Linux kernel or important libraries with gcc3? Will the next version of RedHat be based on gcc3? Daniel Using 3.0.1 dirs would mean change the version string from: gcc version 3.0.2 20010905 (Red Hat Linux 7.1 3.0.1-3) to gcc version 3.0.1 20010905 (Red Hat Linux 7.1 3.0.1-3) which I think would mean even more confusion (since it would not be obvious what CVS is it based on; the directories gcc uses are based on this string). Concerning problems: don't build glibc with gcc3 unless you patch it up, otherwise C libs are just inefficient (they bring in libgcc_s.so eventhough they don't have to if glibc with gcc3 patch is used). Building C++ libraries with g++3 means you have to either rebuild everything C++ with g++3, or make sure the libs don't collide with 2.96-RH C++ libs (stuff like KDE, Qt, Aspell, ...). I think it should be clear what the next version of RHL will be based on (you see /usr/bin/gcc3 in gcc3 package, not /usr/bin/gcc, right?). Watch rawhide to see when we'll start using gcc3 as base compiler... OK. Thanks for your explanations. I am not planning to rebuild everything by myself. I was curious to know what were the problems linked to the release of gcc3. If I understood correctly what you said, there will be a RH7.2 based on gcc2.96 and later on a 8.0 based on gcc3... Am I right?... :) Well, with little luck I might even see Mosix join the team then... :) Thanks for your responses to my simple questions. I wish you a nice day. Daniel |