xgcc passing incorrect options halts bootstrap

[Mark E.]

Now that I'm able to test gcc again, one problem I've been unable to track 
down is a seemingly random failure of the stage1 bootstrap. The bootstrap 
will fail because a bad option was passed to the program xgcc calls. For 
example, here's a failure that happened just a few minutes ago:

----- START LOG EXCERPT -----
stage1/xgcc.exe -Bstage1/ -B/dev/env/DJDIR/i586-pc-msdosdjgpp/bin/ -c  -
DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-
prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H    -I. -I. 
-I/cvs/gcc/gcc -I/cvs/gcc/gcc/. -I/cvs/gcc/gcc/config -
I/cvs/gcc/gcc/../include /cvs/gcc/gcc/c-errors.c -o c-errors.o
Reading specs from stage1/specs
Configured with: /cvs/gcc/configure --srcdir=/cvs/gcc --disable-shared --
verbose --with-gxx-include-dir=/dev/env/DJDIR/include/cxx --with-local-
dir=/dev/env/DJDIR/local --with-gnu-ld --target=i586-pc-msdosdjgpp --
host=i586-pc-msdosdjgpp --prefix=/dev/env/DJDIR --disable-nls --with-
gc=simple
gcc version 2.97 20010108 (experimental)
 stage1/cc1.exe -lang-c -Wno-long-long -I. -I. -I/cvs/gcc/gcc -
I/cvs/gcc/gcc/. -I/cvs/gcc/gcc/config -I/cvs/gcc/gcc/../include -iprefix 
stage1/../lib/gcc-lib/djgpp/2.97/ -isystem include -isystem stage1/include -
isystem c:/djgpp/i586-pc-msdosdjgpp/bin/include/ -D__GNUC__=2 -
D__GNUC_MINOR__=97 -D__GNUC_PATCHLEVEL__=0 -D__MSDOS__ -D__MSDOS__ -
Asystem=msdos -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -g -W -Wall -Wwrite-strings -
Wstrict-prototypes -Wmissing-prototypes -Wtraditional -Wno-long-long -
pedantic -remap -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -
D__tune_i586__ -D__tune_pentium__ -imacros 
c:/djgpp/bin/../include/sys/version.h -DIN_GCC -DHAVE_CONFIG_H /cvs/gcc/gcc/c-
errors.c -quiet -dumpbase c-errors.c -g -O2 -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -Wtraditional -Wno-long-long -pedantic -o 
c:/djgpp/tmp/cc3owW0U.s
 c:/djgpp/bin/as.exe -o c-errors.o c:/djgpp/tmp/cc3owW0U.s
stage1/xgcc.exe -Bstage1/ -B/dev/env/DJDIR/i586-pc-msdosdjgpp/bin/ -c  -
DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-
prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H    -I. -I. 
-I/cvs/gcc/gcc -I/cvs/gcc/gcc/. -I/cvs/gcc/gcc/config -
I/cvs/gcc/gcc/../include /cvs/gcc/gcc/c-lex.c -o c-lex.o
Reading specs from stage1/specs
Configured with: /cvs/gcc/configure --srcdir=/cvs/gcc --disable-shared --
verbose --with-gxx-include-dir=/dev/env/DJDIR/include/cxx --with-local-
dir=/dev/env/DJDIR/local --with-gnu-ld --target=i586-pc-msdosdjgpp --
host=i586-pc-msdosdjgpp --prefix=/dev/env/DJDIR --disable-nls --with-
gc=simple
gcc version 2.97 20010108 (experimental)
 stage1/cc1.exe -lang-c -B/dev/env/DJDIR/i586-pc-msdosdjgpp/bin/ -I. -I. -
I/cvs/gcc/gcc -I/cvs/gcc/gcc/. -I/cvs/gcc/gcc/config -
I/cvs/gcc/gcc/../include -iprefix stage1/../lib/gcc-lib/djgpp/2.97/ -isystem 
include -isystem stage1/include -isystem c:/djgpp/i586-pc-
msdosdjgpp/bin/include/ -D__GNUC__=2 -D__GNUC_MINOR__=97 -
D__GNUC_PATCHLEVEL__=0 -D__MSDOS__ -D__MSDOS__ -Asystem=msdos -D__OPTIMIZE__ -
D__STDC_HOSTED__=1 -g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-
prototypes -Wtraditional -Wno-long-long -pedantic -remap -Acpu=i386 -
Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ -
imacros c:/djgpp/bin/../include/sys/version.h -DIN_GCC -DHAVE_CONFIG_H 
/cvs/gcc/gcc/c-lex.c -quiet -dumpbase c-lex.c -g -O2 -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wtraditional -Wno-long-long -
pedantic -o c:/djgpp/tmp/ccxm34uu.s
cc1.exe: Unrecognized option `-B/dev/env/DJDIR/i586-pc-msdosdjgpp/bin/'
make.exe[2]: *** [c-lex.o] Error 1
make.exe[2]: Leaving directory `d:/cvs/gcc/build/gcc'
make.exe[1]: *** [stage_c] Error 2
make.exe[1]: Leaving directory `d:/cvs/gcc/build/gcc'
make.exe: *** [bootstrap] Error 2

----- END LOG EXCERPT -----

Notice that -B is mistakenly passed to cc1.exe. I've also had failures 
because xgcc passed -W to collect2.exe, and because -o was on the command 
line twice.

The other DJGPP gcc tester (Laurynas) has seen this also. But I haven't 
noticed this problem reported to gcc. So I have to wonder if is a DJGPP 
specific problem (why? I dunno.) or if it is an known problem already.

Mark