Create a MacOS X App Bundle Using MacPorts: Difference between revisions

From Octave
Jump to navigation Jump to search
Line 37: Line 37:
port install qrupdate +atlas+gcc47</nowiki>
port install qrupdate +atlas+gcc47</nowiki>

As a precaution against unexpected problems and a bloated App bundle, using consistent variants for Octave and its dependents is suggested.  For example, when using <code>+atlas</code> make sure none of the dependents are using <code>+accelarate</code>. Also, make sure no dependents are using the <code>+universal</code> variant.  Using the <code>+gcc47</code> variant is also recommended as all of Octave's dependents have a <code>+gcc47<code> variant.  At the very least, following these suggestions will reduce the size of the bundle.  The name of Octave's dependent ports may be determined by the command below.
As a precaution against unexpected problems and a bloated App bundle, using consistent variants for Octave and its dependents is suggested.  For example, when using <code>+atlas</code> make sure none of the dependents are using <code>+accelarate</code>. Also, make sure no dependents are using the <code>+universal</code> variant.  Using the <code>+gcc47</code> variant is also recommended as all of Octave's dependents have a <code>+gcc47</code> variant.  At the very least, following these suggestions will reduce the size of the bundle.  The name of Octave's dependent ports may be determined by the command below.

  <nowiki>port rdeps octave-local</nowiki>
  <nowiki>port rdeps octave-local</nowiki>

Revision as of 08:26, 19 May 2013


Since the initial success with producing a bundle, two things have changed on the Macports end.

  • gcc-4.7 must be used, as some dependencies are no longer supported by gcc-4.5. To look for ports using a gcc45 variant, type port rdeps gcc45 at the terminal's command line.
  • The sudo port mdmg octave-devel @3.6.4+atlas+docs+fltk+gcc47 command fails when bundling the xorg-libx11 port. Review the output of the command port rdeps octave-devel @3.6.4+atlas+fltk+gcc47-x11+no_x11-metis to identify the ports whose variants must be modified to avoid gcc45 and xorg-libx11. There is one dependency (Transfig) for which x11 is not optional. To resolve this, the octave-devel Portfile must be modified and the Transfig run-time dependency removed. This means that Xfig output is not available using Octave's print() function/command.
  • While editing the Portfile for octave-devel, the references to metis should also be removed to avoid a GPL violation.
  • Once the dependencies are resolved, the DMG may be created by sudo port mdmg octave-devel @3.6.4+atlas+fltk+gcc47-x11+no_x11-metis.

Install MacPorts

MacPorts, formerly called DarwinPorts, is a package management system that simplifies the installation of software on the MacOS X and Darwin operating systems. It is a free/open source software project to simplify installation of other free/open source software. Similar in aim and function to Fink and the BSDs' ports collections.

An itemized overview of a MacPorts install is below.

  • Install XCode: This is done via the MacOS X App Store.
  • Follow MacPorts' installation instructions.
  • MacPorts has good support for Octave. A list of what MacPorts has available for Octave is here. To install the most recent version of Octave, type sudo port install octave-devel at the Terminal's command line. Octave has many dependencies which will be downloaded and installed prior to Octave. The entire installation process can take a few hours.

MacPorts has historically been rather good a maintaining their Octave portfiles. However, there are times when the maintainers fall behind. If the current version of the octave-devel port isn't current, it will be necessary to produce a local portfile. For the remainder of this page, it is assume a local portfile is being used and that the port name is octave-local.

Install an Octave Port

MacPorts' Octave port includes the non-GPL METIS. To avoid license violations do not bundle Metis with Octave and then distribute to others. In order to eliminate the Metis dependency, a local portfile may be used, and edited to remove metis. A second motivation to use a local portfile is that the portfiles for the 3.4.x and 3.6.x series did not include all dependencies for the print feature. The missing dependencies are epstool, pstoedit, and transfig. A third motivation for a local portfile is to provide additional flexibility in resolving problems with creating an Octave DMG using the port mdmg ... command .

A prototype portfile which does not depend upon METIS and does depend upon epstool, pstoedit, and transfig has been prepared. After creating a local portfile repository an Octave portfile may be added to the local repository using the commands below.

mkdir -p ~/ports/math/octave-local
cp ~/Desktop/portfile ~/ports/math/octave-local

This assumes the Octave portfile had been placed on the user's Desktop, and that the local portfile repository is located in the users home folder and named ports. After adding the portfile, the local repository must be indexed for MacPorts to recognize it.

cd ~/ports
portindex -f

Once indexed the local Octave port may be installed.

sudo port install octave-local @3.6.4+atlas+fltk+gcc47

The use of the +atlas variant is encouraged as bugs exist for Apple's accelerate framework in both MacOS 10.6 and 10.7. Octave's developers have included a fix for MacOS 10.6, but the fix does not work for MacOS 10.7. There is some commentary on this in various developers discussion forums. For example, see this Homebrew thread (Octave 3.4 fails on lion), this R-Sig-Mac thread (R 2.13.1-patched, vecLib problem on Lion), and the COIN-OR thread (Ipopt - problems on OS X 10.7 Lion). Use of Apple's accelerate framework should also be avoided for arpack<\code> and qrupdate<\code>. To install the recommended variants, use the port commands below.

port install arpack +atlas+gcc47
port install qrupdate +atlas+gcc47

As a precaution against unexpected problems and a bloated App bundle, using consistent variants for Octave and its dependents is suggested. For example, when using +atlas make sure none of the dependents are using +accelarate. Also, make sure no dependents are using the +universal variant. Using the +gcc47 variant is also recommended as all of Octave's dependents have a +gcc47 variant. At the very least, following these suggestions will reduce the size of the bundle. The name of Octave's dependent ports may be determined by the command below.

port rdeps octave-local

The installed variants for each port may be determined by the command below. Be sure to replace "<portname>" with the name of the port.

port installed <portname>

Once an Octave port is installed the command below may be used to determine / verify the version and variants of octave-local which are installed.

port installed octave-local

Install Dependencies with Specific Variants

There may be problems bundling some dependencies. For example, bundling the xorg-libx11 port may fail. To alleviate this problem (or similar ones), the problematic port can be avoided as a dependency. The command used to produce the octave-local DMG, port mdmg octave-local +variant1+variant2+etc, applies the listed variants to each of the dependencies. Therefore, it is necessary to provide a proper aggregate list of dependencies. For Octave 3.6.4, the list below were sufficient.

sudo port mdmg octave-devel @3.6.4+atlas+fltk+gcc47-x11+no_x11-metis+llvm32+ssl+qt

Errors during the execution of this command are likely and may be resolved by modifying the variant(s) of installed packages, and/or modifying the list of variants used to produce the octave-local DMG. One of Octave's dependencies, transfig, requires port xpm, which requires many xorg ports that may cause the port mdmg ... command to fail. To alleviate this problem, the transfig port can be eliminated as a run-time dependency for Octave (can the transfig portfile be modified to eliminate the xpm dependency?).

Create the MacOS X App Bundle

There are effectively four tasks needed to produce the App bundle. First, Octave and all its build and run-time dependencies must be extracted from the MacPorts installation. Second a App bundle template for running a shell script is required. This may be done using the MacOS X AppleScript Editor. Third, the shell script which the App bundle runs is needed. This script will be used to launch the MacOS X Terminal app. This script is referred to as the App's shell script. Finally, a script for setting up the shell environment for Octave and running Octave is required. This script is referred to as the Octave shell script.

Produce a DMG for Octave and its dependencies

MacPorts provides a feature for producing binary packages with standalone binary installers that are precompiled; they do not require MacPorts on the target system. Binary files created with MacPorts may be either .pkg (Mac OS X Installer Packages), or RPM (RPM Package Manager) format. MacPorts may also process a .pkg package into a Mac OS X .dmg disk image file. The port command shown below will create a DMG type binary installer for the Octave port and all its dependencies.

sudo port mdmg octave-devel @3.6.4+atlas+fltk+gcc47-x11+no_x11-metis+llvm32+ssl+qt

In the event errors such as the one below are encountered, the ports implicated (t1lib in this case) must be clean prior to creating the dmg.

Error: Requested variants "+quartz" do not match original selection "".
Please use the same variants again, perform 'port clean gtk2' or specify the force option (-f).
Error: org.macports.mpkg for port octave-local returned: Processing of port gtk2 failed

Be sure to clean each of the problematic ports prior to each attempt to create the dmg.

sudo port clean gtk2

The ports cctools and curl consistently need to be cleaned prior to the port mdmg octave-local ... command. The reason for this is not understood (yet), but one hint is seen during the compilation of the DMG.

Portfile changed since last build; discarding previous state.

The DMG will be placed in the port's work directory. If a local portfile is used, a symbolic link to the work directory will be placed in the directory containing the portfile. In this instance the DMG can be found in ~/ports/math/octave-local/work.

The DMG produced using the prototype portfile's does not include everything needed for Octave. Both macros.texi,, and the files are missing. Until the cause for these missing files is identified and resolved, they will have to be copied manually to the App bundle (one possibility is that the +docs variant is not used. Including the +docs variant would bundle many of the xorg ports as well as all of texlive.

Create an Application Template for Octave

Apple Script Editor Dialog (click to enlarge)

The itemized instructions below describe how to create an application template for Ocave using the AppleScript Editor.

  • Run the "AppleScript Editor" and enter the script below.
# Run the octave shell script that has be bundled.
tell application "Terminal"
	# The script "launch_octave" will call the octave shell script and then close
	# this AppleScript when octave exits.
	do script quoted form of POSIX path of (path to me) & "Contents/Resources/bin/launch_octave '" & (name of me) & "'; sleep 1; exit"
end tell
  • Choose "Save As..." from the File menu.
    • Specify the application name in the Save As: field. For this example, use "".
    • The Where: field specifies the location the application template will be saved to.
    • The File Format: pull down should be set to "Application".
    • Of the Options, only "Stay Open" should be checked.
    • Click on Save.

The launch_octave shell script runs the Octave shell script and uses AppleScript to tell the App bundle to quit when Octave exits.

The default applet.icns file which is included in the App bundle template by the AppleScript editor should be replaced by a MacOS X version of Octave's icon. This MacOS version was produced using the Icon Composer developers utility and a png with a transparent background. The Icon Composer is part of Xcode's developer's tools. Its home is /Developer/Applications/Icon

Populate the App Bundle

To populate the App bundle template with Octave and its dependencies, from MacPorts, follow the itemize instructions below.

  • Move the MacPorts Octave DMG to the Desktop. If a local portfile was used and the location of the local repository was ~/ports, the DMG will be located in ~/ports/math/octave-local/work.
  • Save the original MacPorts installation.
sudo mv /opt /opt-save
  • Install the MacPorts Octave DMG, which as placed on the MacOS X Desktop. Installing the DMG will create a new /opt directory containing Octave and all its build and run-time dependencies. To avoid conflict with the original MacPorts installation.
  • Place the Octave shell script in the same directory as the App bundle template created using the AppleScript Editor.
  • Populate the App bundle by running the script below from the directory containing the App bundle template and the Octave shell script.
#! /bin/sh
cp -pRf ${MACPORTS_PREFIX} ${FULLAPP}/Contents/Resources/.
rm ${FULLAPP}/Contents/Resources/lib/*.a
rm ${FULLAPP}/Contents/Resources/bin/octave
cp launch_octave ${FULLAPP}/Contents/Resources/bin/.
cp octave ${FULLAPP}/Contents/Resources/bin/.
mkdir ${FULLAPP}/Contents/Resources/Applications
cp /Applications/MacPorts/ ${FULLAPP}/Contents/Resources/Applications
  • Restore the original MacPorts installation.
sudo rm -r /opt
sudo mv /opt-save /opt

The Octave App bundle for MacOS X is now ready to run.

Create an Installer DMG

The GPL'd dmgCreater is a Mac OS X Application which allows simple and easy creation of customized dmg disk images with custom background images. It ensures the correct presentation of the disk image's content irrespective of the current Finder configuration.

A short list of features from the dmgCreator sourceforge page are;

  • Create compressed and internet enabled DMG files, i.e. for software distribution.
  • Add a background image and a custom volume icon to your disk image.
  • Add a symbolic link to the Applications folder for easy installation.
  • Show localized license agreements when mounting the disk image. They have to be accepted by the user in order to access the contents.
  • Content positioning at a pixel level.
  • The disk image's content will always look the same, irrespective of the user's finder configuration.

Running Octave from the Terminal's Command Line

The bundled Octave may be run from a terminal command line using the command below.


To create a symbolic link in your path that runs the bundled Octave, us the command below.

ln -s /Applications/ /usr/local/bin/octave

If the link does not work, be sure that /usr/local/bin is in your shell path. If it is not in your path, it may be added by editing ~/.profile. Just add the line below to the end of the file.

export PATH="${PATH}:/usr/local/bin"

Problems, Restrictions, and Annoyances of the App Bundle

  • In the past, the App bundle did not run if there were spaces in its path. A solution to this problem has been applied, but is not fully tested.
  • The Octave shell script used to run Octave is designed to ensure that the bundled version of AquaTerm is used by Octave. This was done because binary incompatibilities have been encountered between the bundled Gnuplot and AquaTerm applications provided by other sources. If Octave/Gnuplot appear to have a problem producing a plot using AquaTerm, verify that Aquaterm is running. If it is not, then quit and relaunch the Octave App. If an Aquaterm application is running, please verify that it is the one bundled with Octave.
  • Executables built by MacPorts may include features specific to the MacOS X version the executables were build on. As a result, the Octave App bundle may not run on a different version of MacOS X.
  • The mex and mkoctfile functions have not been tested. Although the App bundle does include a gcc toolset, some debugging is expected before this will work reliably.
  • When Octave is running, clicking on Octave's icon in the dock has no effect. This is because the App bundle runs a shell script which launches which runs Octave. To locate the Octave session, click on the
  • Only one instance of the App may be run by clicking on the app. Multiple instances may be run from the command line.
  • The Octave binary may attempt to load an library whose version number is older than the one it intended to link to (at build time). This will produce an error like to one below. If this happens, please report the error.
dyld: Library not loaded: /opt/local/libiconv.2.dylib

Fixing "dyld: Library not loaded" Errors

If an error such as the one above is encountered, it is likely due to the Bundle looking in the original install path rather than in the App bundle for the library. This can be fixed using the developer utility install_name_tool.

To point to the correct location for the library, first determine the library's location in the App bundle. In this instance the library's path is Next open a Terminal session, cd to the Resources directory and repair Octave's binary.

cd /Applications/
install_name_tool -change /opt/local/libiconv.2.dylib @executable_path/../lib/libiconv.2.dylib Octave-3.7.0+

To check the binary for other occurances of this problem, type the command below.

otool -L Octave-3.7.0+

Some m-file functions has been written to automate the application of the otool utility toward making the binary executable and dynamically loadable libraries included in the App bundle relocatable. The four m-file functions to accomplish this are itemized below.

 -- Function File: fix_dylibs (EXEBIN, LIBDIR, DRYRUN)
     Make the executable and dynamic libraries relocatable. The inputs

          The full file name of the executable binary for the App
          bundle.  The default is `bin/Octave-3.7.0+';

          The full path to the directory containing the App bundle's
          dynamic libraries.  The default is `lib'.

          If TRUE, the `install_name_tool' commands are printed to the
          command line and are not executed (i.e. the install names and
          paths to the dependent libraries are not changed).  The
          default is TRUE.

     Using `install_name_tool' the portion of the built in dynamic
     library paths external to the App bundles are replaced with the
     token `@executable_path'.  Ths will modify the paths in both the
     EXEBIN and the the dynamic libraries and allow the application to
     be relocated with no risk that the binary executable and libraries
     are unable to locate the dynamic libraries they depend upon.

     In addition to correcting the location information for the
     dependent's of EXEBIN, the LIBDIR is searched recursively to
     locate all dynamic libraries present in the App bundle.  Both
     their install names and the locations of their dependents will
     also be fixed.

     Using the default, this script expects to find a `bin' and `lib'
     directory in the current working directory.
 -- Function File: dylibs = dylibs_find (DIRECTORY)
     Recursively finds all dylibs in DIRECTORY, and returns a structure
     with fields `name', `location', and `dependents'.  The DIRECTORY
     defaults to the present working directory.

          Is the name of a dynamic library.

          Is the path to the named dynamic library.

          Is a cellstr array listing the dynamic libraries the named
          library depends upon.

          Logical scalar indicating whether the file is a symbolic link
          to a dynamically loadable library.
 -- Function File: dylibs = dylibs_get_deps (NAME)
 -- Function File: = dylibs_get_deps (NAME, ROOT)
     Extracts the dependent libary names from the named binary, NAME.
     If ROOT is specified, the only libraries returned will have paths
     which begin with one of the cell-strings contained by ROOT.

     The defaults for ROOT are `{"/opt/local/", "/sw/", "/usr/local/",
     "@executable_path"}'.  These root paths are intended to match all
     the relocatable libraries which should be included in an App
     bundle.  The first and second entries correspond to the MacPorts
     and Fink installation directories, respectively.
 -- Function File: result = dylibs_isdylib (FILENAME)
     Determines if the filename qualifies as a dynamically loaded
     library.  The RESULT is TRUE for dylib-files, oct-files, and
     mex-files.  The result is FALSE for all other files.

     This function isn't sophisticated. It only examines the file

To apply these scripts, change the current directory to, and enter the command below.

dylibs_fix ("bin/octave-3.7.0+", "lib", false)

The script will mirror each of the otool commands to the screen. Errors and/or warnings are given if any libraries are found to be missing in the bundle.

Reducing the Size

The App bundle is large. It's size may be significantly reduced by deleting the static libraries.

find "" -name "*.a" -exec rm -f {} \;


Those interested in testing an App bundle can try (Dated: Sep 8, 2012 at 15:46 PM). The link will be periodically updated. The DMG is large (472+ MB). I kindly ask those with the patience to download it, to report results to bpabbott at mac dot com. Alternatively, if a bug is found file a bug report. When reporting on your experience, please include;

  • The version of MacOS X you are running.
    • Note: This App bundle will not run on Mac OS 10.5 or earlier.
  • The Mac's processor (found under "About This Mac").
  • Whether you have Fink, Homebrew, or MacPorts installed.
  • For intricate problems, please provide enough information so that others may duplicate it.

Testing Results

Results reported by some volunteers testing an App bundle are below. As some of the reported results are inconsistent, individuals are cautioned not interpret these results as definitive. However, the App bundle does appear to run reliably on X86_64 based Macs running MacOS 10.6 and above.

  • An App bundle built for arch=X86_64 on an Intel Core i7 MacBook Pro running MacOS 10.7 was found to run on the following;
  • Macbook Pro (X86_64 architecture) running MacOS 10.8.1.
  • MacBook Pro (Intel Core i7) running MacOS 10.7 with MacPorts installed.
  • MacBook Pro (Intel Core i7) running MacOS 10.7 with no MacPorts, and no Fink, installed.
  • MacBook (Intel Core Duo) running MacOS 10.6 with no MacPorts, and no Fink, installed. The error encountered is below.
$ cd /Applications/
$ ./octave
The application cannot be opened because it has an incorrect executable format.
./octave: line 124: /Applications/ Bad CPU type in executable
  • MacMini (Intel Core 2 Duo) running MacOS 10.6 with Fink installed. The error encountered is below. Enabling 64 bit did not effect this problem. It may be possible for resolved this as the bundled functions properly.
terminate called after throwing an instance of '__gnu_cxx::__concurrence_lock_error'
what():  __gnu_cxx::__concurrence_lock_error
  • MacMini (Intel Core 2 Duo) running MacOS 10.6 with no Fink or MacPorts installed. The error encountered is below.
terminate called after throwing an instance of '__gnu_cxx::__concurrence_lock_error'
what():  __gnu_cxx::__concurrence_lock_error
  • If anyone has advice on how to resolve any of the above errors, please send an email to bpabbott at mac dot com.


List of what can be done to improve the MacOS X App bundle.

  • The macros.texi file doesn't install properly. It should be in share/octave/3.7.0+/etc, but doesn't show up.
  • Enable "linestyle" functionality for Gnuplot's x11 terminal
  • Test the ability to compile mex-files and oct-files.
    • Necessary changes
      • Use the environment variable OCTAVE_HOME in mkoctfile to point to the bundled developer tools and libraries.
      • Same for octave_confgure-3.7.0+
      • Over-ride the built-in octave_configure_info and use an m-file version that replaces the original MacPorts prefix with the OCTAVE_HOME environment variable set by the bundle.
      • The bundled mkoctfile references the gcc4.4 libraries instead of the gcc4.7 libraries that are actually bundled. This needs to be corrected.
    • With the above changes mkoctfile fails with the error below. This is likely due to the script over-riding the build environment variables normally set by mkoctfile.
      • Rely on mkoctfile to setup the oct-file build environment (i.e. don't set any of it up in the .../ script.
      • Since mkoctfile uses it, gsed needs to be added as a run time dependency in the MacPorts portfile. Check to verify that other build time dependencies are not also need.
mkoctfile -v

ld: library not found for -lgcc
collect2: ld returned 1 exit status

"/Applications/" \
-c -I"/Applications/" \
-I"/Applications/" -fPIC \
-I"/Applications/"/.. \
-I"/Applications/" \
-I"/Applications/" \
-I"/Applications/" \
-I"/Applications/" \ -o helloworld.o

"/Applications/" -bundle -bundle_loader \
"/Applications/" -o helloworld.oct helloworld.o \
-L"/Applications/" \
-L"/Applications/" -loctinterp -loctave -lcruft \
  • Should the contents of the la-files, in, be changed to reflect to use the @executable_path token.
    • These files are from libtool. For limited development, such as building oct-files and mex-files, are they needed at all?
  • Use AppleScript Editor to record the creation of the App bundle template.
    • This will allow for a fully automatic build of an App bundle from a shell script.
  • Also use an AppleScript to record the creation of a MacOS X Octave icon.