octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #40606] mxe-octave built octave: fails syscall


From: Michael Goffioul
Subject: [Octave-bug-tracker] [bug #40606] mxe-octave built octave: fails syscalls.cc-tst
Date: Tue, 26 Nov 2013 02:04:44 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

Follow-up Comment #8, bug #40606 (project octave):

Rik,

Is the problem really solved on MinGW? Because it's not for me on MSVC. The
reason is that there's a catch between using "system" and "popen2", how these
are translated into Win32 calls and how they interact with PATH.

When you use "system" in octave, which is translated into "system" from the
Win32 runtime library, PATH is used first, so you end up finding MSYS version
of "sort" (assuming you launched octave from MSYS bash).

When you use "popen2" in octave, this is translated into "CreateProcess" from
Win32 API [1], where lpApplicationName is NULL and lpCommandLine looks like
"\"sort\" \"-r\"". If you read from the documentation how CreateProcess will
lookup for the executable when lpApplicationName  is NULL and the first
element of lpCommandLine does not contain a directory, you'll notice that the
32-bits Windows system directory is searched *before* PATH. And that's
precisely where the windows version of "sort" is located. So even if your
previous "system" call found the MSYS version, the "popen2" call will find the
windows version. And the test will eventually fail.

[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?40606>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]