Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com Reply-To: paulconnell AT clara DOT co DOT uk Subject: Re: Implicit dependency on the existence of /bin/ in make 3.79.1-7 - possible bug Cc: X-Remote_Addr: 195.70.93.15 Message-Id: From: Paul Connell Date: Wed, 21 May 2003 16:34:00 +0100 Interestingly, in the example I gave, if you comment out the line that defines SHELL it works just fine too (presumably defaulting to using cmd.exe) # SHELL=/gibberish/bin/sh .PHONY: all all: ls So I think you're right that perhaps the logic that sets unixy_shell ought to be: 1) If SHELL is defined *in the makefile*, use that value. 2) else try /bin/sh 3) else try and get it from the environment variable SHELL from outside the makefile 3) else try cmd.exe 4) else command.com 5) else fail Perhaps 2) and 3) need to be swapped. I'm not sure of the implications being none-too-familiar with the make source code, or the history of modifications and bugfixes. -- Thanks, Paul > On Wed, 21 May 2003, Paul Connell wrote: > > > Hi. > > > > For historical reasons at my place of work, we maintain a subset of > > some of the cygwin tools for our build processes (e.g. our makefiles > > rely on sed, awk, grep etc). We do this so that we can keep the > > necessary tools in source control (yeah, I know...) and folks don't > > need to have full installs of cygwin cluttering their hard drives if > > they don't want. > > > > The location of these executables is not /bin, and in the general case > > the programmers do not have cygwin 'installed', just the subset from > > out of source control. > > > > Because of this, I have found what may be a problem in v3.79.1-7 of > > make, namely that it can fail in very simple test cases if it is not > > executed within a proper installation of cygwin - which is undesirable > > in our case. > > > > e.g. have a directory c:\gibberish\bin that contains make.exe ls. exe > > and sh.exe -and all related DLLs, which are all the latest versions as > > of May 2003. Put it on your path. Temporarily rename your cygwin / bin > > directory - wherever it is - to /_bin > > > > The following makefile: > > SHELL=/gibberish/bin/sh > > .PHONY: all > > all: > > ls > > > > when processed - 'make -f test.mak' or whatever - will fail with an > > error similar to: > > > > "cannot open /c:" > > > > I believe it may be due to line 33 of main.c in the make source. > > > > It used to say: > > > > /* start off assuming we are using native command shell */ > > unixy_shell = 1; > > > > Now it says: > > > > /* start off assuming we are using native command shell */ > > unixy_shell = access ("/bin/sh", X_OK) == 0; > > > > Note that make v3.79.1-5 works just fine in the same environment, with > > the same makefile. > > > > The other solution I found was to ensure that c:\gibberish\bin is > > mounted as /bin - but that felt a bit hacky, more of a workaround than > > a solution. > > > > Basically, if make is intended to be usable outside of a proper install > > of cygwin, this is a bug. If not, it's not. > > > > Thanks for reading. > > > > -- > > Cheers > > Paul Connell > > Paul, > > I'd guess your problem spans from the following change: > > There is also a change which allows make to default to win32 mode if > /bin/sh is missing. This means that make will use 'command.com' or > 'cmd.exe' if /bin/sh is not available. > > (from ). > > Since this change is Cygwin-specific, and relatively recent, I'm sure the > current make maintainer (Elfyn, IIRC) will consider reasonable > alternatives (especially if they came with patches). One quick solution I > see is to check that $SHELL is set before looking for /bin/sh in make, but > that may have other connotations (e.g., if SHELL is sometimes set outside > of Cygwin, it may screw up current Cygwin installations of make, and we > don't want that). > Igor -- 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/