Bug 59440
Summary: | Problems compiling on RH 7.1 (Maybe glibc problem ?? ) | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <ntpt> |
Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-02 19:21:38 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
2002-02-07 23:48:54 UTC
sorry, misttype ."So, there must be something nasty in gcc 2.2.2-10 and above........" should speak about glibc 2.2.2-10 1 sorry, misttype ."So, there must be something nasty in gcc 2.2.2-10 and above........" should speak about glibc 2.2.2-10 and "downgrade glibc to 2.2.5- 10" should speak about "glibc 2.2-5" Since glibc-2.2.4-19.3 is the official errata glibc for 7.1, I think there is no point to talk about glibc-2.2.2-10. And if you get random non-reproduceable segfaults, it doesn't smell like gcc or glibc bug. Random non reproducable segfaults smell like hw/memory problems. But: With glibc-2.2.2-10. - Segfault ALWAYS (At the same sourcecode line) and unable to continue work (ie building a working kernel) With RedHat official errarta glibc-2.2.4-19.3 Segfault randomly. With old glibc-2.2-5 NO SEGFAULTS and everything works OK.I made intensive tests with this library to be sure, that it work well.(include 4 cycles of standard kernel compiling procedure "make clean make deep bzImage modules" It takes almost all day) I do not thing, that ancient glibc could solve any hardware problem. From my point of wiew, it smell like:glibc-2.2.2-10. introduced some mysterious bug, that was not present in the glibc-2.2-5 and in the relase glibc-2.2.4-19.3 was this bug partially fixed. Any idea what/how to make future tests to track this down ? PS: Execuse my wrong english. Additional info: gcc 2.96-85 + glibc-2.2.4-19.3 work OK (no segfault) if gcc used without -pipe option (ie comment out "CFLAGS += -pipe "in /arch/i386 while compilling kernel) Closing as a two years old and non-reproducable. |