[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Packaging Octave for Windows and OS X (was: writing integer with fwr

From: Paul Kienzle
Subject: Re: Packaging Octave for Windows and OS X (was: writing integer with fwrite)
Date: Tue, 14 Dec 2004 20:56:21 -0500

On Dec 14, 2004, at 5:00 PM, Andy Adler wrote:

On 14 Dec 2004, John W. Eaton wrote:

On 14-Dec-2004, Andy Adler <address@hidden> wrote:

| - The code bloat problem. A static compiled octave is _much_
|   smaller and _much_ more responsive than a dynamically compiled
|   octave. OTOH, dynamic octave allows more flexibility, which
|   pluggable ATLAS, FFTW etc.
|   This problem is so bad that I find that I'm still mostly
|   using the static compiled 2.1.42 version that I made 2 years ago.

I was not aware of this problem.  When I run Octave built with shared
libraries on a Windows system, it seems as responsive as the version I
have on a Debian system.  OTOH, the .oct files do seem to be
considerably larger.  For a very simple one, I see about 220k on the
Windows system vs. 11k for the Debian version (both are stripped).
Does anyone know what is causing this?

You are right; the dynamically linked version is as responsive.
I mean that it takes much longer to load. From the shell, I have
a function that does things like

    echo "1+1" | octave -q

This takes much longer with the dynamically linked version.

What John is seeing is a statically compiled libstdc++.  On my
version I see file sizes of 30k to 130k vs. 10k to 110k on Linux,
which is only 20k extra overhead per file.

Startup times are worse with 2.1.64 at 15 s rather than 10 s for
2.1.50a.  Of this, 5 s is starting the interpreter and the rest
is traversing the octave install tree looking for functions and
PKG_ADD files.  In contrast, 2.1.63+octave-forge for Debian on a
similar machine takes a little over 1 s.  I don't have a static
octave available to compare with, nor a MinGW compile.

| - The windows custom/cygwin problem. We would like to have a
|   version for cygwin, and also one that has a custom NSIS based
|   installer.

Why?  What advantage does an NSIS installer have over creating Cygwin
packages and using the Cygwin installer?

The NSIS installer provides an *.exe installer that works the way
windows users expect (and is less complicated to explain than the
cygwin installer). It makes links to 'octave' the way a windows Matlab
user is used to.

To be honest, when I'm using a 'foreign' computer, and I need a
quick install of octave, I choose the NSIS version rather than
the cygwin installer.

Agreed.  Cygwin is cumbersome to install and I prefer not to have
the support costs of explaining it to the end users of my software.
It's bad enough that I have to explain Octave when what they really
want is the application software.

I have been plugging away at the install process over the past year.
The octave-forge download site contains precompiled supporting libraries.
The admin/Windows directory contains a Makefile which does all the
work of building a new octave for windows release.  The install script
still needs some work (like testing it for example), then it will be
ready for a new release.

Now that I think about it, the best would be an NSIS installer
that automatically gets the latest cygwin package and installs
it into a custom minimal cygwin environment.

How about an NSIS installer which can create a link to /opt/octave-2.1.xx
in the existing cygwin, and link the binary to /usr/bin/octave?

- Paul

Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]