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
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.
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.
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).
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.