Messages in this thread | | | From | "Osvaldo Pinali Doederlein" <> | Subject | Compilation problem (bug?) | Date | 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/
| |