This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Portability fix

[cc: cygwin mailing list -- original message at]

>> 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/ 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
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"
-#if defined IN_GCC && !defined GENERATOR_FILE && !defined USED_FOR_TARGET
-# include "insn-constants.h"
-# include "insn-flags.h"
 #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) 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: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]