>> For the past month or so, make restrap has been randomly broken under >> cygwin. >> >> I have traced it to tm.h and tconfig.h not always getting rebuilt >> correctly, though I really have no idea why it didn't work with make >> restrap, but was fine with a clean make bootstrap. Maybe it is just >> a sh bug under cygwin, nevertheless this patch fixes it and actually >> is a bit more readable, IMO. >> >> OK? > > I sure would like to know why this is borken under cygwin. It seems > like a fairly simple construct which should work fine, AFAICT. > > cgf
I agree in principle (though the patch makes the script easier to read).
The offending command line cut and pasted from the makefile log looks like:
TARGET_CPU_DEFAULT="" HEADERS="config/i386/i386.h config/i386/unix.h config/i386/bsd.h config/i386/gas.h config/dbxcoff.h config/i386/cygming.h config/i386/cygwin.h defaults.h" DEFINES="" /bin/sh ../../gcc-snapshot/gcc/mkconfig.sh tm.h
If I just run this command in the GCC directory then tm.h is built correctly.
If this file is created via a "make tm.h", "make bootstrap", or just plain "make", then tm.h is also built correctly.
However, if this file is created via a "make restrap" then the lines between the cat <<EOF
...
EOF
get uncermoniously dropped on the floor as can be seen in this diff comparsion.
$ diff -u tm.h tm.h.borked --- tm.h 2003-11-13 13:46:44.756119500 -0500 +++ tm.h.borked 2003-11-13 13:46:29.053383500 -0500 @@ -10,8 +10,4 @@ # include "config/i386/cygwin.h" # include "defaults.h" #endif -#if defined IN_GCC && !defined GENERATOR_FILE && !defined USED_FOR_TARGET -# include "insn-constants.h" -# include "insn-flags.h" -#endif #endif /* GCC_TM_H */
The only real difference I can see is that "make restrap" adds one additional layer of make recurrsion since it calls "make bootstrap" which in turns the calls "make stage1" and so forth.
I tried to hack the makefile to add an strace to before the $(SHELL) mkconfig.sh command, but that has the side effect of causing the script to work again :).
The script also works fine if SHELL=/bin/bash.
So the basic answer to your question is I don't know exactly why /bin/sh is borked. I am open to suggestions for checking though.
Kelley Cook
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
