From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10109161409.AA04737@clio.rice.edu> Subject: Re: Build problems To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) Date: Sun, 16 Sep 2001 09:09:05 -0500 (CDT) Cc: djgpp-workers AT delorie DOT com In-Reply-To: from "Eli Zaretskii" at Sep 16, 2001 09:22:19 AM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > This was caused by crt0.o being in upper case > > Any idea how did crt0.o get renamed to upper case? Yes. I probably did the "make" for that file with lfn=n. Since lfn=n was a quick workaround for many of the bugs, and a very quick way to test to see if problems went away, it's not uncommon for me to have some of these upper case files lying around on the tree. > > I was surprised we were case sensitive here. > > Make is case-insensitive only when LFN is off (because then things > won't work at all if we don't down-case file names and truncate them > to 8+3 limits). > > Getting Make to be really insensitive to file-name letter-case > requires heavy changes in Make sources, since it uses strcmp, and > there's no clear indication whether the compared strings are file > names or parts thereof, or just strings. So I decided not to do that > after considering the issues involved. OK, no problem. I was just *really* confused why it was doing this, now I know. If it were not for make -d and that cryptic message - I'd probably still be looking ... Since make clean doesn't wipe out the crt0.o (or anything in lib or bin in the cvs build tree) - when this was left in the wrong case it broke the build and I couldn't understand why (thinking it was some new bug in W2K). > Can you post a sample of commands or targets where you get "Bad > command or file name" messages? That might give a clue where to look > for possible causes. A libc "make" certainly shows it very early - I think when definining some symbols (shell built-in)? Something in popen or similar? What is even more interesting is I get additional strings to the screen which should not go there (redir -eo make -d > x.x) extract: Reading makefiles... Reading makefile `makefile'... Reading makefile `../makefile.lib' (search path) (no ~ expansion)... Reading makefile `../makefile.inc' (search path) (no ~ expansion)... Reading makefile `../makefile.def' (search path) (no ~ expansion)... _creat reopen OK on c:/djgpp/tmp/dj100000 (debug fprintf) _creat reopen OK on c:/djgpp/tmp/dj400000 Bad command or file name _creat reopen OK on c:/djgpp/tmp/dj500000 c:/djgpp/lib/gcc-lib/djgpp/2.953/libgcc.a (should be setting LIBGCCA) _creat reopen OK on c:/djgpp/tmp/dj600000 djgpp-x.djl Reading makefile `makefile.oi' (search path) (no ~ expansion)... So it appears our make shell commands are not working reliably with the broken _creat. > (Yes, you guessed it: my wife got a notebook with W2K Professional.) Welcome to the W2K club. Be nice to her so she'll let you borrow it :-)