Creating a standalone application from Octave script file

Problem description

Hi, I created a Octave script and it work nicely.
Now, I want to give a distributable release of this script to my collegues, but without installing Octave software. I want to give them a simple software that they can execute whenever they want.
How can I do that? I found this official notes (and this similar question) but are hard to understand for me since I am not expert of informatics.

Can you help me? Thank you.

My system

Ok, what the guide and stackoverflow answer give is that you can create a standalone application using C++ that has access to Octave libraries and functions, because by itself octave isn’t a language that can compile it’s code to create a executable program, because using octave what you create are scripts that are interpreted.

then it gives you the example:

#include <iostream>
#include <octave/oct.h>

main (void)
  std::cout << "Hello Octave world!\n";

  int n = 2;
  Matrix a_matrix = Matrix (n, n);

  for (octave_idx_type i = 0; i < n; i++)
    for (octave_idx_type j = 0; j < n; j++)
      a_matrix(i,j) = (i + 1) * 10 + (j + 1);

  std::cout << a_matrix;

  return 0;

all of that was written in C++.

The part:

#include <octave/oct.h>

is a part where the C++ program specifies that will be using a Octave header file called oct.h that will allow the C++ program to call the functions and libraries from Octave, then the standalone file is created by running a command to compile in the command line or terminal called mkoctfile, everything after mkoctfile are “the instructions to create” the application called “standalone”:

$ mkoctfile --link-stand-alone -o standalone

Then they test the standlone application by “opening it” in the terminal:

$ ./standalone

The program works because the terminal showed:

Hello Octave world!
  11 12
  21 22

Then the program ends and terminal is available to write commands again:


but this “standalone application” needs octave installed and only offers access to its Math libraries, because as the guide says it this only dynamically links the octave libraries to the C++ program.

It does not, however, allow the script files, oct-files, or built-in functions of Octave to be used by the application. **To do that, the Octave interpreter needs to be initialized first.** An example of how to do this can then be seen in the code.

Then it procceds to show you how you write a C++ program that includes other important octave files and intializes the octave interpreter to work with it:

#include <iostream>
#include <octave/oct.h>
#include <octave/octave.h>
#include <octave/parse.h>
#include <octave/interpreter.h>

main (void)
  // Create interpreter.

  octave::interpreter interpreter;

      // Inhibit reading history file by calling
      //   interpreter.initialize_history (false);

      // Set custom load path here if you wish by calling
      //   interpreter.initialize_load_path (false);

      // Perform final initialization of interpreter, including
      // executing commands from startup files by calling
      //   interpreter.initialize ();
      //   if (! interpreter.initialized ())
      //     {
      //       std::cerr << "Octave interpreter initialization failed!"
      //                 << std::endl;
      //       exit (status);
      //     }
      // You may skip this step if you don't need to do anything
      // between reading the startup files and telling the interpreter
      // that you are ready to execute commands.

      // Tell the interpreter that we're ready to execute commands:

      int status = interpreter.execute ();

      if (status != 0)
          std::cerr << "creating embedded Octave interpreter failed!"
                    << std::endl;
          return status;

      octave_idx_type n = 2;
      octave_value_list in;

      for (octave_idx_type i = 0; i < n; i++)
        in(i) = octave_value (5 * (i + 2));

      octave_value_list out = octave::feval ("gcd", in, 1);

      if (out.length () > 0)
        std::cout << "GCD of ["
                  << in(0).int_value ()
                  << ", "
                  << in(1).int_value ()
                  << "] is " << out(0).int_value ()
                  << std::endl;
        std::cout << "invalid\n";
  catch (const octave::exit_exception& ex)
      std::cerr << "Octave interpreter exited with status = "
                << ex.exit_status () << std::endl;
  catch (const octave::execution_exception&)
      std::cerr << "error encountered in Octave evaluator!" << std::endl;

  // Shutdown the interpreter which cleanly releases all memory.
  interpreter.shutdown ();

  return 0;

Again it creates the program with mkoctfile and tests it by running the program name embedded in the terminal:

$ mkoctfile --link-stand-alone -o embedded
$ ./embedded
GCD of [10, 15] is 5

Since i have never try it, i’m not sure about the stackoverflow answer, but it seems logical in it’s reasoning:

  • Step 1: Create a stand-alone executable, with C++ as the guide explained it, specially the embedded program part

  • Step 2: Create a distribution folder

You will need to create a copy of many of the Octave files. I suggest a directory specifically for this. At a minimum, you will need a copy of all or most of the DLLs in \bin. Additionally, place your distributable executable in this directory.

  • Step 3: Other files whack-a-mole

You will now need to find out what other files will be necessary to run your .m script. You can simplify this step by copying \oct\i686-pc-mingw32*.oct and \share\octave\3.2.4\m**.m to the distribution directory, although this will be overkill, and will not actually prevent the whack-a-mole step.

That is, what he is doing is copying the octave files in the octave directory to a folder where the main executable of his standalone application would be.

It certainly would be better if the creation of standalone programs could be made simpler and automated, i’ve looked and there were some proposals years ago to make translators/compilers to take the octave source and convert it to C++ code and then compile to make executables, it would certainly be great since by itself octave offers, clean simple solutions for scripting numerical and linear algebra calculations.

This functionality is what the “Matlab Compiler” offers for Matlab: It’s not actually a compiler; it just creates a standalone application by bundling up M-code source files with a library that runs a headless Matlab interpreter.

Octave could offer something similar, and there’s been a bit of discussion about it, but no plans to make it. Mostly because we don’t think there’d be much demand for it: because Octave is free, any user receiving an Octave-based program can just download Octave to run it, unlike Matlab, which requires an expensive license. And Octave is large: a Windows Octave installation is multible GB on disk; bundling a separate Octave runtime in your application would make it similarly large. It’s a little hard to see how this would be better than just using a regular Octave installation as the runtime for Octave files. Though I could certainly see a case for a tool that bundled up Octave programs in a way that made them easier to run (from the Windows graphical shell or a command line) and so they could discover the required Octave installation(s) easily, and maybe pop up a prompt telling the user to install Octave if one was not found.

1 Like

Hi apjanke,
Though I understand your points there are still some reasons that could invite Octave to consider an evolution in the sense mentioned by AlbiRomb.

-In multidisciplinar teams there are some members that only want to use a tool that you have to developed for them. They do not want to open a program (octave/matlab) to run a tool from inside it. In the end, if the tool could be a simple .exe or .sh, it would be a big help for the developer. Otherwise, there are always problems with the installation and these “IT muggles”.
-In a second case, I have the feeling that if I could compile (or something similar) my .m octave codes they would run faster. In this case I do not get the paper of mex and oct files and, somehow I do not understand their existence if, once you learn to ‘code’ in octave, you cannot create your mex/oct files.

I may be wrong in my points of view as it might be too personal but, in my opinion, they would be a reason to continue with octave instead of migrate, for example, to python.

Kind regars,

It should be easy enough to write a .bat or .sh script that just calls Octave with the name of the script to run. This is no different from giving them a shell script that calls a Python script. They still have to have the Python interpreter installed.

There is no speed benefit to bundling a standalone Octave interpreter with m-files. The m-files are still interpreted, just as they are for any other interpreted language like Python or Perl.

If you want the benefits of a compiled language the code actually needs to be written in a compiled language. Octave lets you choose a wide variety of languages such as Fortran, C, or C++ for the compiled language. And because many other languages (for example, Python) have API bindings to C or C++ the choice is even wider.

Yeah. There’s no benefit to “compiling” in the sense that the Matlab Compiler does things; it’s just a deployment and packaging tool. And producing a tool that “compiled Octave .m code for real” in a manner that applied generally to all Octave code and actually sped things up would be very difficult; I give that like a 1% chance of actually happening.

jaimepi might be thinking of something like the Matlab Coder (MATLAB Coder - MATLAB, which does produce faster-running C/C++ code from M-code. But it only works on a very restricted set of the M-code language; many language features and standard library functions are not supported.

In fact, IIRC, someone was working on a Coder thingie for Octave at some point? Or am I imagining that?

This is, as you say, a very difficult problem. It’s sort of the Holy Grail of computing. I would like the computer to program itself to run faster. When it can do that, we won’t need human programmers.

Probably you mean this one? Testing the OctaveCoder.

1 Like

Yes, that’s the one!

Thanks a lot @apjanke and @siko1056
Some of your comments are more educational than many forums.
Bear in mind that some people “program” what we can without being IT engineers. We have learned by necessity and changing languages can be costly.

Indeed, I thought that compiling any code meant speeding up. Sorry.
Thank you very much for the idea of calling octave with a batch or sh. It seems silly but I hadn’t thought about it.

Sometimes compiling also means hiding a specific function so that it cannot be copied though a kind of *.p files, as matlab do, could be enough the most of the cases.

Thank you so much for the octave2oct !! I did not know about it. I hoep it works, I am going to try it right now.

Hey, that’s not your fault for misunderstanding! Usually compiled code, or a compiled language, is faster. I think this is Matlab’s fault for using the name “Matlab Compiler” for a tool that doesn’t really compile things. That’s why I’m putting “compiling” in scare quotes here. :wink:

The specific thing that p-coding to *.p files does is usually called “obfuscating”.