From: SF/projects/mingw n. l. <min...@li...> - 2011-11-17 01:57:27
|
Bugs item #3438189, was opened at 2011-11-15 01:15 Message generated for change (Comment added) made by ozhiker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3438189&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MSYS Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ozhiker (ozhiker) Assigned to: Charles Wilson (cwilso11) Summary: Perl incorrect dependence on "sh" rather than "sh.exe" Initial Comment: Hi MinGW Perl seems to have a dependence on "sh" rather than "sh.exe" when executing external programs. This means that if the path contains both a windows "sh.exe" and a linux "sh", perl will attempt to execute the wrong one. This is a problem if, as I am you are attempting to make a toolchain that works both in windows and linux. To recreate the problem: * obtain http://ozhiker.com/mingw/test.zip * unzip * cd <unzip-dir>\test\bin\ * perl test.pl -> Error message: <unzip-dir>\test\bin\perl.exe: *** couldn't commit memory for cygwin heap, Win32 error 0 * delete "test\bin\sh" * perl test.pl -> works as expected Test system : Windows 7 - files from latest MinGW release ---------------------------------------------------------------------- >Comment By: ozhiker (ozhiker) Date: 2011-11-16 17:57 Message: Yes - Using the older version of perl.exe, the "sh" file was ignored and the perl program executed normally using "sh.exe". Using the latest perl.exe, the "sh" file is not ignored and causes the error message. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-11-16 04:58 Message: I am going to assume you mean that the "new behavior" is the "couldn't commit memory for cygwin heap, Win32 error 0" message. Certainly not the fact that an executable script coming first in the PATH will be executed, that is not "new behavior". If what I say is true then you need to correct your bug report Summary. ---------------------------------------------------------------------- Comment By: ozhiker (ozhiker) Date: 2011-11-15 20:29 Message: This is a new behaviour - I had a previous version of MinGW perl.exe from about a year ago which did not have this problem. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-11-15 04:36 Message: I'm leaning toward won't fix but I'll give Chuck a chance to weigh in on the issue. It is expected that PATH is set such that it doesn't contain such a trap and the users environment is under the users control which isn't an issue for MinGW developers. We deliver MSYS such that the paths are set by the MSYS environment and if a user modifies his environment then it is the users responsibility to ensure that the added paths do not interfere with the working environment. We have no control over the PATH beyond what is delivered by default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3438189&group_id=2435 |