bugGNU Octave - Bugs: bug #40381, MXE / MinGW - setenv does not work...


bug #40381: MXE / MinGW - setenv does not work correctly

Submitted by:  John Donoghue <lostbard>
Submitted on:  Sat Oct 26 17:49:31 2013  
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: John DOpen/Closed: Closed
Release: devOperating System: Microsoft Windows

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Wed Nov 13 16:57:14 2013, comment #41:

The original bug, setenv on MinGW, seems to have been fixed, so I'm going to close this report. Any other issues, such as failing tests, can be put under a new bug report.

Rik <rik5>
Project Administrator
Mon Nov 11 18:15:54 2013, comment #40:

Running debug using the cross build mxe:

John Donoghue <lostbard>
Project Member
Mon Nov 11 02:35:46 2013, comment #39:

Looking over the failed tests, one caught my eye.

I think it would be worth setting a breakpoint in ndgrid and then single-stepping through the code to see where the problem lies. ndgrid.m is a short file so it should be easy.

Rik <rik5>
Project Administrator
Sun Nov 10 20:34:53 2013, comment #38:

For running the installed (native compiled octave), I end up with:


PASS 11293

See the file test/fntests.log for additional details.

245 (of 831) .m files have no tests.

John Donoghue <lostbard>
Project Member
Sun Nov 10 13:34:03 2013, comment #37:

I compiled last night using the latest make dist devel tarball of 3.7.7+ in mxe-octave cross build and native build and installed.

Both ran ok in regards to the program running from octave.exe.

Running the tests gave a number of failures, each stopped and core dumped when they were doing the jit tests.

I have attached a partial diff of the test results file from both the cross/native installed version.

(file #29584)

John Donoghue <lostbard>
Project Member
Sun Nov 10 04:41:41 2013, comment #36:

Let's assume for the moment that it is a problem with libtool and run-octave. What happens if you do actually install octave, 'make install', and then try running the installed octave executable? If it loads correctly, does '__run_test_suite__ ()' pass most tests?

Rik <rik5>
Project Administrator
Sat Nov 9 13:39:20 2013, comment #35:

Something with the libtool execute?

If I change the name to something wrong, exec returns back an error, so it is getting running something ok.

If I add a print statement in main-gui.cc, it is not displayed.

John Donoghue <lostbard>
Project Member
Fri Nov 8 14:25:43 2013, comment #34:
John Donoghue <lostbard>
Project Member
Fri Nov 8 01:57:38 2013, comment #33:

Can you add this statement to line 372 of main.in.cc.

When you then do run-octave it should print out what filename it is trying to execute.

Rik <rik5>
Project Administrator
Fri Nov 8 00:45:46 2013, comment #32:

It was still yesterday

John Donoghue <lostbard>
Project Member
Fri Nov 8 00:05:01 2013, comment #31:

Is the problem with run-octave not working still present on MinGW? The code base has been changing every day pretty significantly for the last 5 days.

If it is still present, I think we might need to put in some printf() statements to see what is going on.

Rik <rik5>
Project Administrator
Sun Nov 3 01:27:32 2013, comment #30:
John Donoghue <lostbard>
Project Member
Sat Nov 2 22:36:18 2013, comment #29:

Offhand, the script is complaining about missing the octave executable. Do you have a file src/octave which is executable? Or is it only src/octave-cli and src/octave-gui? If it is there, does it have the correct extension?

Rik <rik5>
Project Administrator
Fri Nov 1 16:35:31 2013, comment #28:

I was running the windows (native compiled) version.

I have pulled since but still show the same issue.

run-octave.in (and run-octave) have the following in their arg parsing:

Running './run-octave -cli' still works.

Running others without the run-octave script:

John Donoghue <lostbard>
Project Member
Fri Nov 1 13:58:47 2013, comment #27:

What hg id were you using for your tests on minGW?

Also, you mentioned the '-cli' option. Did you mean '--no-gui-libs'? There isn't any such option on the Linux version.

Finally, could you try these three tests?

Rik <rik5>
Project Administrator
Fri Nov 1 01:25:40 2013, comment #26:

if I run: ./run_octave -clii, the command line version runs fine.
If I change the octave_executable variable in run_octave to octave-gui, the gui runs ok.

John Donoghue <lostbard>
Project Member
Fri Nov 1 00:53:17 2013, comment #25:

On compiling the docs in native ming:

Running run-octave from the build directory fails:

John Donoghue <lostbard>
Project Member
Wed Oct 30 10:48:56 2013, comment #24:

My native ming version is doing a couple of weird things still, but I believe they were self inflicted when I was playing around with trying to get it to run, so I am rebuilding mxe and octave to check it is working.

John Donoghue <lostbard>
Project Member
Tue Oct 29 20:28:10 2013, comment #23:

@ John (JWE): your fix works OK for me; the /bin subdir is added to the PATH now when executing octave.exe directly, and octave-gui.exe is started. On my WinXP box:

/bin has been added twice, but that isn't in the way.

Is it really necessary to add the libexec/.../i686-pc-mingw32 subdirs to the PATH? (not that it is harmful in any way) - I see no difference with the current situation and the previous one where I only had /bin added (by calling Octave from a batch file that first added (only) /bin to the PATH).

Do we leave it to John Donoghue to close this bug?

Philip Nienhuis <philipnienhuis>
Project Member
Tue Oct 29 11:13:15 2013, comment #22:

I don't (= can't in MXE presently) build with LLVM either, and Java only has 2 tests ATM (in ov_java.cc).
Didn't you see the 20 classdef test FAILs? Perhaps they are properly skipped in your case.

As to the PATH setting, does Octave now add OCTAVE_HOME/bin to the (Windows) PATH in its process? Couldn 't track that down in your latest series of patches (I'm no C++ expert).

I'll try to rebuild & test tonight.

Philip Nienhuis <philipnienhuis>
Project Member
Tue Oct 29 05:37:54 2013, comment #21:

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


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.

This does improve the situation for me with the tests. Now I'm seeing 11402 PASS, 22 FAIL, 4 XFAIL, and 55 SKIPPED. I'm not building with LLVM or JAVA, so that's probably why the skipped count is so high.

Now that Octave can properly set the PATH before executing programs, I'm not seeing the messages about makeinfo. I am still seeing a series of permission denied errors from system-tst about date.m. It looks like it is searching the load path for date.m and giving a permission denied error about the file in each directory of the load path. I don't know what that's about, but anyway things look a lot better to me now than they did this time yesterday...

John W. Eaton <jwe>
Project Administrator
Tue Oct 29 01:39:20 2013, comment #20:

There was a minor typo in 7ae9bc04ec07, fixed in 34d9812a943b, so the octave command should run the GUI again now. Can't comment on the rest.

Mike Miller <mtmiller>
Project Administrator
Mon Oct 28 23:08:58 2013, comment #19:


I just tried the tip 17784:7ae9bc04ec07 (MXE cross build on WinXP)

1. When closing octave (CLI and GUI), I now see an error message flashing by:

(Text could be a little different as it shows maybe 0.25 sec before the Octave windows disappears).

2. When starting octave.exe, I get the CLI; with or without the --force-gui flag makes no difference.
I need to explicitly start octave-gui.exe to start the GUI.
From the post you referred to I can't figure out whether that is the intended behavior (but OK it is bed time here).

Starting octave-gui with --no-gui flag makes octave-cli start.

Please interpret the following just as a report. If it is like you expect, good, please ignore.

Starting Octave from a cmd32 command prompt ("Windows shell") gives funny results:

... so once octave is started, hitting the Enter key switches between the cmd32 terminal and the Octave prompt. Although / while an octave prompt is displayed, it doesn't seem that octave accepts octave commands.

Now, running octave-cli from a command prompt behaves as expected:

Same goes for octave-gui.exe, only the error message is shown in the terminal pane.

Philip Nienhuis <philipnienhuis>
Project Member
Mon Oct 28 21:07:52 2013, comment #18:

There was also some discussion about this on the maintainers list. My last post is here:


The thread is "gui/pager problem on MacOSX".

John W. Eaton <jwe>
Project Administrator
Mon Oct 28 20:59:44 2013, comment #17:

Never mind last question, found reason in the log (changeset 17778:b5d58667d32d). Sorry

Philip Nienhuis <philipnienhuis>
Project Member
Mon Oct 28 20:37:05 2013, comment #16:

OK, found fntests.log in OCTAVE_HOME/bin (remarkable that Windows search didn't find it - I must have misspelled the name).

Apart from the new FAILs this binary runs fairly well.

What was the reason to have another Octave binary? I didn't catch that on the maintainers ML or in the bug tracker.
(At first sight it looks just more complicating, but (as always) you'll probably have good reasons for it.)

Philip Nienhuis <philipnienhuis>
Project Member
Mon Oct 28 19:33:59 2013, comment #15:

I checked in the following changeset for the OCTAVE_HOME problem:


John W. Eaton <jwe>
Project Administrator
Mon Oct 28 17:54:42 2013, comment #14:

The fntests.log file should be created in whatever is your current directory when you run _run_test_suite_.

Yes, I already noticed the problem with OCTAVE_HOME substitution. The problem is that main.cc doesn't have the code to automatically detect the current installation directory to set OCTAVE_HOME. It is just looking in the environment for OCTAVE_HOME. I'll see if I can fix that so it is detected automatically.

John W. Eaton <jwe>
Project Administrator
Mon Oct 28 17:46:43 2013, comment #13:

Reporting test results poses a problem as fntests.log is nowhere to be found.
In an (MXE-cross) octave build from yesterday I found it in the OCTAVE_HOME subdir (i.e., "root dir") itself. But in today's build (hg id see above) it seems it isn't created.

A more positive thing is that I saw no makeinfo issues.
In the %TEMP% dir I found loads of octave-help-<random string> files, all containing \texinfo text. Based on their time stamp I think these are made during _run_test_suite_ operation.

Anyway, from the messages scrolling by on XP I see 39 FAILS and on Win 7 37; no idea why that is different. The fntests.log from yesterday's build shows:

- conv2.cc yields 7 FAILS (also on Linux)
- bug38236 yields 1 FAIL (also on Linux; "vr undefined")
MinGW-specific (i.e., not seen on Linux):
- data.cc 4 FAILS (Inf vs NaN as usual on MinGW)
- quadgk: max_recursion_depth exceeded
- classdef (20 FAILs) - wonder why it counts those on a non-classdef build
- system.cc: file attributes (always fails on MinGW as Windows file attributes are different)
- syscalls.cc: AFAICS CRLF versus LF line ending issues
- assert.m: some less easily diagnosed FAILs
plus a few more (no time now to scrutinize the fntests.log).

Usually MinGW builds have 10-12 FAILS; discounting the 20 classdef ones there are now a few more (assert, quadgk, syscalls). Hopefully I can have a look at those by the end of this week.

Philip Nienhuis <philipnienhuis>
Project Member
Mon Oct 28 16:51:57 2013, comment #12:

An MXE (cross-)built octave.exe (17780:8b353af4a1ca) won't start the GUI on my WinXP & Win7 systems.
octave-gui.exe itself works OK AFAICS.
On Win7 I get:

==> Looks like this is again a build-versus-install path problem a la bug #40284.

I'll try to run tests & report on that later.

Philip Nienhuis <philipnienhuis>
Project Member
Mon Oct 28 16:22:51 2013, comment #11:

The new options-usage.h file is in the hg archive but I listed it in the wrong place in libinterp/Makefile.am so it didn't appear in the tarball. That problem should be fixed in hg now.

John W. Eaton <jwe>
Project Administrator
Mon Oct 28 12:29:32 2013, comment #10:

Trying to compile a native mingw version to see if it works with ALL the latest commits :) ...

Under my native build I always get complaints/errors about not being able to build the documentation due to missing tex stuff - unless I am compiling a dist version, which usually works ok.

John Donoghue <lostbard>
Project Member
Mon Oct 28 10:29:14 2013, comment #9:

I will take that back - it did not compile.

make[5]: *** No rule to make target `options-usage.h', needed by `all-am'. Stop.
make[5]: *** Waiting for unfinished jobs....
mv dldfcn/tsearch.cc-tst-t dldfcn/tsearch.cc-tst
/home/jade/mxe-octave/tmp-octave/octave-3.7.7+/libinterp/octave.cc:68:27: fatal error: options-usage.h: No such file or directory
#include "options-usage.h"
compilation terminated.

John Donoghue <lostbard>
Project Member
Mon Oct 28 10:25:47 2013, comment #8:

I compiled octave id b5d58667d32d last night successfully with the latest mxe (patcahed for the 3.7.7+ number and checksum change) and it compiled ok.

I havent tried running it yet, but will when I get the chance.

Unfortunately I will be out for a day or two and will only have the ability to compile/run native mingw code until I get back.

John Donoghue <lostbard>
Project Member
Mon Oct 28 06:49:12 2013, comment #7:

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...

John W. Eaton <jwe>
Project Administrator
Sun Oct 27 18:57:49 2013, comment #6:

See the post I was referring to - Octave's GUI crashes when closing from the main menu (File | Exit).
Ctrl-d never gave issues.

BTW since a few weeks I also need a batch file (to add <OCTAVE_HOME>/bin to the PATH for the newest Octave development versions; indeed to be able to run mkoctfile, unzip, gzip, etc.).

Until that time I just started octave-3.7.7+.exe directly and then somehow the /bin subdir always automagically got added to the end of the Windows PATH of Octave's process (as per getenv("PATH"); sometimes it even got added twice). I didn't investigate further.

Older Octave vesions on Windows didn't require a batch file either, at least until 3.6.4, nor Michaels 3.7.2+ MSVC snapshot binary. In this respect it is remarkable that newer versions do need one. The putenv() messages you see could be related (though that may be a red herring).

Philip Nienhuis <philipnienhuis>
Project Member
Sun Oct 27 18:06:43 2013, comment #5:

maybe - how were you running octave? I havent been able to cause it to crash since running from a bat file.

I couldn't get ctrl-d to lock up running either way. (lately at least)

John Donoghue <lostbard>
Project Member
Sun Oct 27 17:26:52 2013, comment #4:

As to the crashes in comment #1, could this question by me from two weeks ago be related?


(No bug report at the time as I couldn't pinpoint it down exactly. But it used to be consistent behavior.)

Philip Nienhuis <philipnienhuis>
Project Member
Sun Oct 27 13:05:02 2013, comment #3:

If I run octave from a .bat file (in windows as needed for mkoctfile etc to work correctly), then the issue goes away and everything appears to work.

John Donoghue <lostbard>
Project Member
Sun Oct 27 12:28:56 2013, comment #2:

If this happens with the cross build but not the native build, then I suspect that there is some difference in configuration that causes the problem. Probably in one case you are getting the gnulib setenv code and the other you are not. Can you determine whether that is happening?

John W. Eaton <jwe>
Project Administrator
Sat Oct 26 18:17:10 2013, comment #1:

Actually, it looks to be intermittent. Sometimes it will display error: putenv: Not enough space when running setenv.

Other times setenv and getenv works.

It does appear that after setenv works and I go to close the GUI, octave crashes.

As mentioned before, this doesn't occur with my native build version of the code.

John Donoghue <lostbard>
Project Member
Sat Oct 26 17:49:31 2013, original submission:

Using the latest dev 3.7.7+ (25-Oct-13) cross compiled with latest mxe octave base and installed on a Win 7 machine.

John Donoghue <lostbard>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #29584:  test.diff added by lostbard (7kB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by lostbard (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Nov 13 16:57:14 2013rik5StatusNeed Info=>Fixed
    Sun Nov 10 13:34:03 2013lostbardAttached File-=>Added test.diff, #29584
    Fri Nov 8 01:57:38 2013rik5StatusNone=>Need Info

    Back to the top

    Powered by Savane 3.1-cleanup