Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 32078 - Bad: gcc crashes while compiling gnustep-base
Bad: gcc crashes while compiling gnustep-base
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-03-17 04:06 EST by Need Real Name
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-21 14:17:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tarbal with the GSString.mi produced with -save-temps -v flags from several releases of gcc (42.87 KB, type/bzip2)
2001-03-21 14:13 EST, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2001-03-17 04:06:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2 i586)

On a k6-200 system, while trying to complile the gnustep-base package
(www.gnustep.org), there is a segmentation fault.

Reproducible: Always
Steps to Reproduce:
1. get
2. rpm --rebuild gnustep-base-0.9.3-1.src.rpm

Actual Results:  The compilation started, and after several files processed
there was a segmentation fault when reaching the GSString.m file.

Expected Results:  complile to the end!

gcc GSString.m -c  -DGNUSTEP_INSTALL_PREFIX=/usr/GNUstep/System
-DGNUSTEP_TARGET_DIR=\"ix86/linux-gnu\" -DGNUSTEP_TARGET_CPU=\"ix86\"
-DGNUSTEP_TARGET_OS=\"linux-gnu\" -DLIBRARY_COMBO=\"gnu-gnu-gnu-xgps\" 
-D_REENTRANT  -fPIC -DGSWARN -O2 -m486 -fno-strength-reduce -Wno-import
-fgnu-runtime   -I../Headers/gnustep -I../Headers -I./ix86/linux-gnu    -I.
-I/usr/GNUstep/System/Headers -I/usr/GNUstep/System/Headers
-I/root/GNUstep/Library/Headers -I/usr/GNUstep/Local/Library/Headers
-I/usr/GNUstep/Network/Headers/gnustep -I/root/GNUstep/Headers/gnustep
-I/usr/GNUstep/Local/Headers/gnustep -I/usr/GNUstep/System/Headers/gnustep 
-I/usr/GNUstep/System/Headers/ix86/linux-gnu -I/root/GNUstep/Headers
-I/usr/GNUstep/Local/Headers -I/usr/GNUstep/Network/Headers
-I/usr/GNUstep/System/Headers  -o
GSString.m:1769: Internal error: Segmentation fault.
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
gmake[3]: *** [shared_obj/ix86/linux-gnu/gnu-gnu-gnu-xgps/GSString.o] Error
gmake[2]: *** [libgnustep-base.build] Error 2
gmake[1]: *** [libgnustep-base.all.library.variables] Error 2
gmake[1]: Leaving directory
gmake: *** [internal-all] Error 2
Comment 1 Jakub Jelinek 2001-03-21 07:54:08 EST
Which gcc-g77 rpm do you use (there was one Objective-C GC bug fixed
about a month ago)?
Can you please rerun the above command line with -save-temps -v flags
and post here GSString.mi it creates?
Comment 2 Need Real Name 2001-03-21 14:13:38 EST
Created attachment 13283 [details]
tarbal with the GSString.mi produced with -save-temps -v flags from several releases of gcc
Comment 3 Need Real Name 2001-03-21 14:17:04 EST
I have tried  that with gcc-2.96-69 (from redhat updates), gcc-2.96-71 (from
fisher beta version) and gcc-2.96-75 (from wolverine beta version). Of course in
each case I installed all the relevant packages (cpp, gcc, gcc-objc, gcc-c++,
libstc* etc). In all the cases I received a seg. fault while processing the
GSString.m file. The problem was always reproducible! I am attaching the
GSString.tar.gz file which contains 3 files:
GSString.69.mi, GSString.71.mi, GSString.75.mi which were produced by the
corresponding release of gcc. A simple gcc <filename> on my system (RH7.0,
k6/200) reproduces the seg. fault always!
Comment 4 Jakub Jelinek 2001-03-22 04:22:02 EST
It is the Objective C GC collection bug (implemented_classes not registered
with GC), which is fixed since gcc-objc-2.96-76. I can reproduce it with -75
but cannot with -79, and with -75 it dies in the implemented_classes handling

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