Re: Problems with the Windows build

[Michael Goffioul]

On Tue, Oct 29, 2013 at 1:41 AM, John W. Eaton <address@hidden> wrote:

On 10/28/2013 02:52 AM, John W. Eaton wrote:

[I also posted the following information to the bug #40381 (the PATH
setting was suggested in one of the comments in that report). --jwe]

I tried building current Octave (hg id = 8b353af4a1ca) with mxe-octave
(hg id = e7cb2340feff+; changes only in the version number and sha1sum
for the Octave tar file that I generated).

When I copy the resulting binary to my Windows 7 system and run
__run_test_suite__, it fails a number of tests, some with a message
about not finding makeinfo not recognized as an internal or external
command, operable program, or batch file. But system ("makeinfo
--version") displays the makeinfo version info as expected.

This message doesn't show up until later in the tests, so I thought
maybe we were accumulating open files or something similar that was
preventing Octave from opening program files to run. So I tried
running only the fixed tests, but that doesn't seem to avoid the
problem.

Then I tried running Octave from inside an msys terminal window after
setting PATH as suggested and it crashes with a segfault in the fsolve
test.

I'm also noticing a number of times when the GUI appears to hang and I
get a spinning cursor. It usually comes back after 5-10 (or maybe
more) seconds, but I have no idea what is going on during the delay.

Ugh, we can't release like this...

Following up on this, the errors about not finding makeinfo were
apparently caused by the bug in setenv.  Here's what I posted about
this in the bug tracker:

I checked in the following change to fix the setenv/putenv problem. It
seems to work for me.

http://hg.savannah.gnu.org/hgweb/octave/rev/415583856971

I guess this is the reward I get for trying to fix a memory leak. :-(

It would probably be better to figure out why gnulib::setenv isn't
working, but for now I'm going with this change.

I believe it's the same issue as reported in this thread [1]. The problem has been fixed in gnulib's putenv, but when I look at the gnulib's setenv module, I think it suffers from the same problem. Basically, manipulating directly the "environ" global variable has no effect on child processes and is not inherited by them (in the Win32 C runtime library).

Michael.

[1] http://lists.gnu.org/archive/html/bug-gnulib/2013-02/msg00065.html