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