Compilation problem (bug?)

Osvaldo Pinali Doederlein (osvaldo@visionnaire.com.br)
Fri, 26 Mar 1999 18:02:16 +0100


Hi,

I have just upgraded to egcs 2.91.66 and other new libs (RPM distributions:
egcs-1.1.2-11, egcs-c++-1.1.2-11, glibc-2.1-0.990222, libstdc++-2.9.0-11)
and then I wanted to rebuild the kernel 2.2.4 (which I had built
successfully before, with egcs-1.1b and glibc-2.0.something)... the 'make
zImage' bombed here:

make[3]: Entering directory `/usr/src/linux/drivers/scsi'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fom
it-frame-pointer -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-ju
mps=2 -malign-functions=2 -DCPU=686 -c -o scsi.o scsi.c
scsi.c: In function `scan_scsis_single':
scsi.c:766: `TYPE_ENCLOSURE' undeclared (first use in this function)
scsi.c:766: (Each undeclared identifier is reported only once
scsi.c:766: for each function it appears in.)
scsi.c: In function `resize_dma_pool':
scsi.c:2480: `TYPE_ENCLOSURE' undeclared (first use in this function)

I checked the sources, at linux/drivers/scsi/scsi.c at line 766:
case TYPE_ENCLOSURE:

This symbol doesn't seem to exist anywhere else in the sources, except the
two offending places according to the compiler. At
linux/include/scsi/scsi.h, there is a list of device types:

#define TYPE_DISK 0x00
#define TYPE_TAPE 0x01
#define TYPE_PROCESSOR 0x03 /* HP scanners use this */
#define TYPE_WORM 0x04 /* Treated as ROM by our system */
#define TYPE_ROM 0x05
#define TYPE_SCANNER 0x06
#define TYPE_MOD 0x07 /* Magneto-optical disk -
* - treated as TYPE_DISK */
#define TYPE_MEDIUM_CHANGER 0x08
#define TYPE_NO_LUN 0x7f

but this list does not include TYPE_ENCLOSURE, I guess that's where it
should be defined.

I guess the old compiler was just warning on this code and ignoring the case
in scsi.c:766 and one expression term in scsi.c:2480. More likely, I think
the compiler was assuming that the unknown TYPE_ENCLOSURE is an undeclared
function, and by default interpreting it as an 'int ()' function, and taking
its address as a valid value for both places where it's used, and for some
additional bizarre reason (optimization?) not bombing at linking time?...
well, I ain't a Linux hacker by any stretch of mind so I'm sorry if the bug
report is bogus (I didn't find related msgs in the archives).

I was able to compile after commenting out both uses of TYPE_ENCLOSURE, and
the compilation proceeded without further problems and my new kernel is
happy as usual. I guess the proper fix, if the bug is real, is adding a
#define TYPE_ENCLOSURE 0x09 in scsi.h.

A+
Osvaldo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/