bugGNU Octave - Bugs: bug #41296, build mkoctfile and octave-config...


bug #41296: build mkoctfile and octave-config as executables on all platforms

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Wed 22 Jan 2014 03:41:34 AM UTC  
Category:  Configuration and Build System Severity:  4 - Important
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  Mike Miller <mtmiller>
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

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


( Jump to the original submission)

Fri 24 Jan 2014 05:47:33 PM UTC, comment #16: 

I fixed the segfault with myfeval.c in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/d1e16bdb3958).  I was just trying to cast away the 'const' attribute and I had accidentally changed the type which was leading to the segfault.

I made a few more modifications to the documentation, but everything looks fine now so I'm going to close this report.

Rik <rik5>
Project Administrator
Fri 24 Jan 2014 02:29:43 PM UTC, comment #15: 

Rik: only when running from inside of Octave, but these can be run from Forge package configure scripts or Makefiles.

Thanks for cleaning that substitution code up. Here are the differences between the old and new that I see now with this change. These are probably good changes, just noting the slight differences now in case it does affect somebody.

$ mkoctfile-old -p OCTAVE_HOME
# empty string
$ ./src/mkoctfile -p OCTAVE_HOME
$ export OCTAVE_HOME=/foo
$ octave-config-old -p PREFIX
$ ./src/octave-config -p PREFIX

So in other words, octave-config now keeps PREFIX to the compiled-in directory, it used to substitute OCTAVE_HOME into the PREFIX variable as well. And mkoctfile now prints the value of PREFIX when OCTAVE_HOME is requested but it is not in the environment.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Fri 24 Jan 2014 08:44:50 AM UTC, comment #14: 

I checked in the following change so that main.in.cc, mkoctfile.in.cc, and octave-config.in.cc will all use the same functions for setting and substituting OCTAVE_HOME:


It works for me on my Debian system but I didn't test on Windows yet.

John W. Eaton <jwe>
Project Administrator
Fri 24 Jan 2014 08:43:30 AM UTC, comment #13: 

I checked in the following change to make the list of variables the same in mkoctfile.m and mkoctfile.in.cc:


John W. Eaton <jwe>
Project Administrator
Fri 24 Jan 2014 07:16:36 AM UTC, comment #12: 

The attached patch makes myfeval.c work for me.

(file #30359)

John W. Eaton <jwe>
Project Administrator
Fri 24 Jan 2014 06:21:35 AM UTC, comment #11: 

Shouldn't OCTAVE_HOME always be defined?  From within octave itself

octave:1> help OCTAVE_HOME
'OCTAVE_HOME' is a built-in function from the file libinterp/corefcn/defaults.cc

-- Built-in Function:  OCTAVE_HOME ()
     Return the name of the top-level Octave installation directory.
octave:2> OCTAVE_HOME
ans = /home/rik/downloads/local

which is accurate.

Rik <rik5>
Project Administrator
Fri 24 Jan 2014 06:15:20 AM UTC, comment #10: 

I see that the file mkoctfile.m has a different list of flags for the -p print option than the mkoctfile executable.  Try

help mkoctfile


mkoctfile -h

from the command line.

Rik <rik5>
Project Administrator
Fri 24 Jan 2014 06:12:05 AM UTC, comment #9: 

I compiled all of the sample pieces of code in the examples directory with the new mkoctfile.  I found a lot of out-of-date material in the documentation which I fixed here (http://hg.savannah.gnu.org/hgweb/octave/rev/adb7c7e6a4a1).

One major problem I found was that myfeval.c leads to a segfault.

octave:1> mex myfeval.c
octave:2> myfeval ("sin", 1)
panic: Segmentation fault -- stopping myself...
Hello, World!
I have 2 inputs and 0 outputs
I'm going to call the function sin
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault

It might be some new problem with my machine because I tried it with past versions of Octave (3.6.4, 3.4.3, 3.2.4) and I also got a segfault.

Rik <rik5>
Project Administrator
Fri 24 Jan 2014 05:55:49 AM UTC, comment #8: 

I compared the values of all of the variables for mkoctfile -p and octave-config -p against the shell scripts, with and without OCTAVE_HOME defined. I pushed a fix for octave-config that was stripping PREFIX when OCTAVE_HOME was not defined.


Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Thu 23 Jan 2014 09:49:48 PM UTC, comment #7: 

I updated the .cc file versions.  I think they are consistent with the script versions now.  I wouldn't be surprised to find a few problems in the future, but I think these should work.


John W. Eaton <jwe>
Project Administrator
Thu 23 Jan 2014 06:02:06 PM UTC, comment #6: 

I just did a small test and the help output is different between the executable and the script file.  The script file mentions '-pthread' as an option.

Rik <rik5>
Project Administrator
Thu 23 Jan 2014 05:43:02 PM UTC, comment #5: 

Thanks for committing that, I didn't have time to take care of it yesterday. Test time was mostly my reason for suggesting gui-release, but this will be great to get into the next stable release.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Thu 23 Jan 2014 04:30:47 PM UTC, comment #4: 

I pushed Mike's changeset to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/ee7f66925267) so that it can be a part of 3.8.1.  It's ready for test/comparison with the existing script version.

Rik <rik5>
Project Administrator
Wed 22 Jan 2014 08:01:46 PM UTC, comment #3: 

I'll compare the two versions of mkoctfile and octave-config.  You can go ahead and commit the change and then I'll compare the new C++ versions with the last sh versions.

John W. Eaton <jwe>
Project Administrator
Wed 22 Jan 2014 05:30:52 PM UTC, comment #2: 

Should the fix happen on the stable branch?  Even though this is a relatively big change it sort of seems like it has to happen if mkoctfile is going to work on cygwin.

There are a number of other reports about mkoctfile which would probably be easier to solve if we had just a single source file.  In particular, we probably should pass on unrecognized flags directly to the compiler  (see bug #34169).

Is anyone volunteering to do the consistency checking between the compiled and script versions before we get rid of the script version?

Rik <rik5>
Project Administrator
Wed 22 Jan 2014 05:47:34 AM UTC, comment #1: 

Yes, it has been discussed several times in the past.  One of the reasons for not doing it was that it was easier for users to tweak a shell script instead of a compiled program.  By that logic, then maybe all of Octave should be a shell script.  :-)

I was reminded of (and annoyed by) this issue again today when I was thinking of making some changes to mkoctfile.  It's annoying to have to make changes twice, and difficult to ensure that the programs don't diverge from one another.  While I was working on mkoctfile, I noticed some differences between the shell script and the C++ program.

So you can count me as in favor of the change.

John W. Eaton <jwe>
Project Administrator
Wed 22 Jan 2014 03:41:34 AM UTC, original submission:  

I am pretty sure this has been brought up before but not yet addressed. I would like to modify the src directory to build mkoctfile and octave-config as executables unconditionally. We currently have to maintain two independent implementations for these programs, simply because we can do shell scripts on Unixy systems but not on Windows. If we have to do executables on Windows, then we might as well only maintain the C++ implementations.

This is related to bug #41249, the mkoctfile and pkg commands are currently broken for 3.8.0 on cygwin.

Attached changeset removes the conditional and builds the mkoctfile and octave-config executables on all systems. Works for me on Debian. I made this on the default branch, but I think this change should be suitable for gui-release, let me know what you think.

I have to note that I have not gone through all of the options and variables in these programs to ensure that they match up perfectly between the two implementations.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.


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

Attach Files:

Attached Files
file #30359:  diffs.txt added by jwe (686B - text/plain)
file #30333:  auxprogs.diff added by mtmiller (26KiB - text/x-patch)


Depends on the following items: None found

   bug dependencies.


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

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

    Only project members can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-24 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2014-01-24 jwe Attached File- => Added diffs.txt, #30359
    2014-01-23 rik5 Severity3 - Normal => 4 - Important
    2014-01-23 rik5 StatusPatch Submitted => Ready For Test
    2014-01-22 mtmiller Dependencies- => bugs #41249 is dependent
    2014-01-22 mtmiller Attached File- => Added auxprogs.diff, #30333

    Back to the top

    Powered by Savane 3.5