Bug 59440 - Problems compiling on RH 7.1 (Maybe glibc problem ?? )
Summary: Problems compiling on RH 7.1 (Maybe glibc problem ?? )
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc   
(Show other bugs)
Version: 7.1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-07 23:48 UTC by Need Real Name
Modified: 2007-04-18 16:40 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-02 19:21:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2002-02-07 23:48:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Description of problem:
Problems compiling on RH 7.1 (Maybe glibc problem ?? )
I experience following problem : gcc2.96-81 crash while compiling kernel. 
(Segmentation fault). If I reboot and "make" (with or without prior issue 
of "make clean" ) again,then it crashes at the same line..... 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Standard kernel compiling procedure.

make menuconfig
make dep
make bzImage...

Actual Results:  Internal error: Segmentation fault.
Please submit a full bug report.

****** please read Additional information about this bug !!!

Expected Results:  compiling working kernel

Additional Information:

I upgraded gcc to 2.96-85(As recomended solution for this bug 31168 
in "bugzilla" ) , but problem persists. 

I make some examination of this, beause just few hours later I compiled the 
same kernel souce code on the same machine (Machine K6-2_3D/300, 96MB Ram, 
255MB swap space,in most cases, there is no more swap space used than 128 kb. ) 
but runing RH 7.0,kernel 2.4.10 with absolutely no problems. 

I increased Ram to 128 (brand new dimm module) and added another 64 MB to swap 
space to avoid memory hw fail + kernel memory/swap problems. NO effect. 

For the same reason I tried to boot machine  with different kernels I have 
(2.4.10 , 2.4.3(from RH) ,2.4.16 and 2.2.16-22(From RH) ) and compile again.No 

I downgraded GCC to 2.96-54 ,the same version as on the previous instalation,( 
where it runs without problems )... No effect. 

If I change the glibc from 2.2.2-10 to 2.2.4-19.3 for RH7.2 ( rpm --nodeps...), 
it works in many cases, gcc makes segfault only occasionaly and after segfault 
I can run "make" again and continue with compilation (Part of source code,that 
cause segfault now compiles OK ) and It produce working kernel(!).....

If I downgrade glibc to 2.2-5 ("rpm --upgrade --oldpackage --force --
replacefiles"), everything works fine.(I try to make full compilation 
procedure   "make clean menuconfig dep bzImage modules" 4 times without an 
error).It work ifne even with gcc upgradet to  gcc 2.96-85...  

So, there must be something nasty in gcc 2.2.2-10 and above........

downgrade glibc to 2.2.5-10

PS: downgrading glibc also solved problem with long execution 
time/failing/crashing/freezing of "ssh-keygen" program.....

Comment 1 Need Real Name 2002-02-08 00:35:56 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

Comment 2 Need Real Name 2002-02-08 00:53:57 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 and "downgrade glibc to 2.2.5-
10" should speak about "glibc  2.2-5"

Comment 3 Jakub Jelinek 2002-02-08 10:38:00 UTC
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.

Comment 4 Need Real Name 2002-02-10 23:35:29 UTC
Random non reproducable  segfaults smell like hw/memory problems.


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.

Comment 5 Need Real Name 2002-02-12 00:40:39 UTC
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)

Comment 6 Richard Henderson 2004-10-02 19:21:38 UTC
Closing as a two years old and non-reproducable.

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