Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 24529

Summary:	gcc 2.96-69 pre-processor fails to create in-line code
Product:	[Retired] Red Hat Linux	Reporter:	Polo Talnir <polo_talnir>
Component:	gcc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:	David Lawrence <dkl>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.0	CC:	polo_talnir
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:	2001-01-22 19:46:14 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 Polo Talnir 2001-01-22 01:05:07 UTC

gcc 2.96-69 compilation (or rather cpp) of SCSI driver aic7xxx.c
for Adaptec card leaves strcpy() unresolved and could not be then
inserted into the kernel. The strcpy() should have been compiled
in-line according to the strings.h header file. This happens
in % make modules with settings for suport of SCSI Adaptec card as
a module.

To reproduce setup kernel configuration (%make xconfig, eg.) for
compilation of Adaptec SCSI support, do a % make modules;
% cd to the SCSI modules directory,
% nm aic7xxx.o | grep str; you should see strcpy as unresolved.

Comment 1 Jakub Jelinek 2001-01-22 10:35:54 UTC

gcc makes no guarantees that a function will be inlined, that's just a hint.
Anyway, if you attach here the preprocessed source of the file you end up
with strcpy not inlined, I can have a look (just repeat the gcc command
line you see in the log with additional -save-temps -v arguments), attach here
aic7xxx.i plus the gcc command line used.

Comment 2 Polo Talnir 2001-01-22 19:46:11 UTC

Truly, the unresolved was memcpy() and not strcpy(). See bug
# 24522 and your response. My mistake. Your response to
# 24522 describes this.

As per the NEEDINFO status, unfortunately as I needed to compile
the module for the 2.2.17 kernel I rolled back 2.96 to egcs once I
discovered that egcs works. But I presume this is a known (a duplicate)
bug, per your comments to #24522

Do I understand correctly that in 7.0 RH distribution I have egcs as
"kgcc" and there is no need to downgrade gcc 2.96 to egcs to
compile the kernel? Should I change the makefile to compile with kgcc?

In your comments to bug #24522 you write:
+You should not compile 2.2.17 kernel with gcc but kgcc (= egcs), only 2.4
+kernels can be built with gcc 2.96-RH (you could get undefined memcpy/memset
+references as well).

Comment 3 Jakub Jelinek 2001-01-23 09:58:24 UTC

Yes, if you are compiling 2.2.x kernels, you should use kgcc.
If you compile 2.2.18 or above, it will automatically pick kgcc, while
with 2.2.17 and earlier you have to tell it to do so.
One way is e.g.
make CC='kgcc -D__KERNEL__ -I$(HPATH)'
or change the CC line in toplevel Makefile.
BTW: kgcc stands for Kernel gcc.