Date:	Sun, 26 Jan 1997 17:18:51 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Daisuke Aoyama <jack AT st DOT rim DOT or DOT jp>
cc:	DJGPP WORKERS <djgpp-workers AT delorie DOT com>, DJ Delorie <dj AT delorie DOT com>
Subject:	RE: Configure scripts
In-Reply-To:	<199701241702.CAA15303@mail.st.rim.or.jp>
Message-ID:	<Pine.SUN.3.91.970126170015.6498H-100000@is>
MIME-Version:	1.0

On Sat, 25 Jan 1997, Daisuke Aoyama wrote:

> Eli Zaretskii wrote:
> 
> > 	* change "test -f" to "test -x"
> > 	* fix any filenames illegal on MSDOS (like config.h.in)
> 
> Where did you modify?
> In my case, configure script was not modified.

That's because you defined $CC and other environment variables, so the 
script used their values instead of searching the $PATH.  I deliberately 
didn't set these variables, because I wanted to see if it will work that 
way.  When I change `test -f' to `test -x', it does--almost (see below).

> But I found a problem
> about detection. configure sctipt searches time_t declaration in
> sys/types.h. In DJGPP, it  has no declaration.

<sys/types.h> includes <sys/djtypes.h> which has a macro to declare 
time_t, but <sys/types.h> doesn't invoke that macro.  DJ, is that an 
omission?  If not, then the configure script that you are trying to run 
(from bash, right?) is just looking in the wrong place.

However, I think I've found a serious shortcoming of the feature which
converts d:/path into //d/path.  The problem is only visible when you have
more than a single disk drive, and some of the directories on your $PATH
are on a drive other than the current drive.  Suppose I have C: and D:,
and my PATH is thus: 

	PATH=C:\BIN;D:\DJGPP\BIN

and suppose I'm running configure script from a directory on drive C:, 
and further suppose that I've set thus:

	set SYSROOT=c:
	set PATH_SEPARATOR=:

(these are a must if you need to run configure scripts).  Now, the $PATH 
inside bash is converted like so:

	PATH=/bin://d/djgpp/bin

So far, so good.  Now configure starts looking for gcc in every directory
on the PATH.  If my gcc.exe is in d:/djgpp/bin, the script won't find it,
because when you call `stat' with a filename like "//d/djgpp/bin/gcc.exe",
it fails, since the DJGPP library knows nothing about such pathnames. 

So, for this nifty feature to really work, bash needs to convert the 
pathnames back to their usual form before passing it to any built-in 
commands or programs invoked by bash.  Otherwise, some complex scripts 
would fail unless you work on a single-drive machine (or use JOIN 
trickery to make a drive look as a subdirectory).

I realize that this might be very hard to fix, but I think this is a 
serious problem that should be corrected even if the cost is high.

- Raw text -