On 10 Sep 99, at 9:44, Peter Gerwinski peter@gerwinski.de wrote:

The African Chief wrote:

...

Like I said before, I can't do anything with "configure" under Win32. The system simply fails to recognise the script as something that it can execute.

Maybe the script expects a program "\bin\sh.exe" because the first line reads "#!/bin/sh". This problem once occured under DJGPP ...

"sh.exe" exists, but not in "/bin". The /bin stuff is a unix thing (who has ever heard of "/bin" under any other OS?). I amended it to remove the "/bin" prefix so that "sh" gets executed. However, this does not help.

...

This is so even when trying to run the script under Bash. Since this script seems really to be a unix thing, perhaps an alternative could be made for non-unix systems? - basically, either to translate the "configure" script into batch commands that the Dos or Windows command interpreters can process (which is probably impossible, because the script seems too complex to translate into a Dos batch file) or to write a Pascal (or C) program that does everything that the "configure" script does. [...]

The second thing would be possible but unwise: The script is generated automatically and re-built with each version of GCC.

Hmmm ... can the same thing that generates this script also generate a C program to do the same thing? Surely the GCC guys care about non-unix platforms?

The right solution would be to make `mingw32' complete enough to run the script (as has been done for DJGPP). Besides `bash', the "text utils" and "shell utils" are needed (see DJGPP).

AFAICS all these utilities exist for Cygwin32 (they all seem to be there in my Cygwin32 directory tree). Mingw32 can use the Cygwin32 tools alright. It is only the libraries that are different. Personally, I would be happy if I could compile GPC for either Cygwin32 or Mingw32. The only real difference is a large DLL that Cygwin32 programs require (to implement the unix emulation layer for Windows).

In any case, the problem here is more fundamental than these. The configure script itself cannot even be recognised as something that can be executed. If that first hurdle can be crossed, then one can begin to worry about the remaining utils.

What I did in fact do for EMX where I also could not run the `configure' script was to generate `Makefile', `p/Makefile', `p/rts/Makefile' and (IIRC) some `*config*.h' files manually (by manually changing the corresponding `*.in' files while looking what `configure' had done before for Linux). The same can certainly be done for mingw32 - of course with the drawback that the work has to be repeated each time the underlying GCC version changes.

In which case, would it be easier to write a program to do the job?

(Nevertheless it can be an interesting exercise to do this work now for gcc-2.8.1 or egcs-1.1.2 and repeat it in a few days/weeks when GPC can run with gcc-2.95.x.;-)

Perhaps the GCC guys can try to minimise the changes (or even optionally to generate a C program instead of (or in addition to) the script?). I guess they might not be too concerned with Pascal, or with non-unix people, to bother too much about all this.

...

PS: Perhaps I can get bash to run the script. If I try to run "configure.in", bash seems to start trying to run it, and then finally chokes. However, with "configure", it just says that the file does not exist - which is not true. Doing "ls -all config*" shows that the attributes of "configure.in" are "-rw-r--r--", while those of "configure" are "-rwxr-xr-x". Is the difference significant?

Yes - `x' means "eXecutable".

...

If so, what parameters do I pass to "chmod" so as to change the attributes of "configure" to the same one as "configure.in"?

chmod +x configure.in

But it will not run.

The problem is the other way round. Bash tries (without success) to run "configure.in", but claims that "configure" does not exist. So, it seems to recognise "configure.in" as something that can be executed, despite the fact that the "x" is not in its attributes.

All this is giving me a headache. Perhaps I should just stick with Law .... :-/

Best regards, The Chief --------------- Dr Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro v5.20a for Win32 ftp://ftp.simtel.net/pub/simtelnet/win95/install/chief52a.zip Email: laa12@keele.ac.uk http://ourworld.compuserve.com/homepages/African_Chief/

...

Doing "ls -all config*" shows that the attributes of "configure.in" are "-rw-r--r--", while those of "configure" are "-rwxr-xr-x". Is the difference significant?

Yes. "x" is "executable" bit. So in normal (unix-like OS) you can execute configure but not configure.in ... Execute with just "./configure" command taht is.

To be sure, in DJGPP you have two ways to "run configure"

- first way: first boot bash from dos prompt (e.g. >), by typing e.g.

bash -login

when you have the bash prompt (e.g. $) you type $ ./configure --prefix=c:/djgpp

-second way directly from dos prompt type simply:

bash configure --prefix=c:/djgpp

Both methods work. --prefix is mandatory because the default is /usr/local which does not exist under DOS. What are you doing exactly?

On the other hand you need to create sh.exe from bash.exe In djgpp you have two ways

copy bash.exe sh.exe

or make a symlink

ln -s bash.exe sh.exe

the second is more economical because it creates only a short file (2048 bytes) which calls bash, but both work. In djgpp bash translates silently

/bin/sh

to

%DJDIR%/bin/sh

i.e. for example

c:/djgpp/bin/sh

I don't know what it does under mingw32, but this is certainly crucial.

Any how you could try to circumvent it by putting sh.exe in a dir /bin directly at root of your disk.