Support Requests item #497594, was opened at 2001-12-29 07:34
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=497594&group_id=2435
Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Andrey Reznik (dront)
>Assigned to: Earnie Boyd (earnie)
Summary: configure problems
Initial Comment:
Hello,
please help me with my problem.
When i've tried to use mingw under cygwin
enviroinment, i found a problem: configure scripts
from some programs began to fail. Everything was good
when I did use cygwin itself...
What i mean by 'fail':
There is a check "checking $(MAKE) variable" in that
scripts. To perform it, such script creates a Makefile:
all:
@echo '"$(MAKE)"'
(or @echo 'some_var="$(MAKE)"')
and runs make (at this time - make from mingw, not
from cygwin).
It produces string as
\/cygdrive/c/mingw/bin/make.exe"
(notice \ instead of " ), and eval fails.
What is wrong here?
----------------------------------------------------------------------
>Comment By: Earnie Boyd (earnie)
Date: 2002-08-05 16:41
Message:
Logged In: YES
user_id=15438
Old request. - Closed.
----------------------------------------------------------------------
Comment By: Wirawan Purwanto (wirawan0)
Date: 2002-02-20 17:59
Message:
Logged In: YES
user_id=206371
Well... I have experienced the same, too. I believe that
this is a persistent bug in Mingw's make. I am using
Mingw's Make version 3.79. And by using cygwin's make.exe,
I get rid of this problem at all. Note: I am using Windows
2000 pro here.
Wirawan
----------------------------------------------------------------------
Comment By: Andrey Reznik (dront)
Date: 2002-01-22 07:21
Message:
Logged In: YES
user_id=363962
OS - WinNT
Yes, I use cygwin version of sh.exe, surely it is a
problem.
At this time I just skip this problem, using Cygwin's
version of Mingw.
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2002-01-08 20:09
Message:
Logged In: YES
user_id=11494
What OS? (Win9x/ME or NT/W2000)
I see the problem, and also how to fix.
One fix would be to assume that every one who uses the
mingw version of make also uses the cygwin version of
sh.exe. That is the cleanest (in the code) but not
acceptable for obvious reasons. If we can assume a cygwin
sh.exe, we may as well just point users to the cygwin
version of make.
Another fix would be to force subprocs to be run as
scripts: the code for that is already in place, but needs
to be forced with compile-time flag when building make.
The drawback is that the tmp script (or batch files
depending on whether make finds any sh.exe or not) may not
be deleted if make fails so you get loose turds floating
around in tmp directory. Other drawback is that the dir
chosen as tmp may not be writeable if user hasn't defined
TEMP or TMP environment variable.
Care to test the latter fix on your system?
Danny
----------------------------------------------------------------------
Comment By: Andrey Reznik (dront)
Date: 2002-01-08 02:39
Message:
Logged In: YES
user_id=363962
No, it's another problem.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-12-29 18:10
Message:
Logged In: NO
I don't know if this is your problem, but for me, running configure scripts with make and gcc from MinGW and the ash shell from Cygwin fails when checking if make sets $MAKE.
The culprit is that somewhere inside the configure script, there's something like "make whatever 2> something," which in theory should pipe the errors (2 is the handle to the standard error output) from make and spit them into the file something.
Unfortunately, if you use the make in MinGW, it will interpret the command as meaning make the target named whatever, and the target named 2. Redirecting the standard error output doesn't seem to work in this case.
The easiest fix is just to use make utility from Cygwin. it seems to handle the redirecting properly.
Hope that helps.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=497594&group_id=2435
|