Re: Implicit dependency on the existence of /bin/ in make 3.79.1-7 - possible bug

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

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 <http://cygwin.com/ml/cygwin-announce/2002-05/msg00010.html>).

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
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton


--
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/