Re: Mingw32 compiled binaries

[Benjamin Lindner]

> > It's especially appealing due to the fact that you can include the
> compiler
> > in the package, which is not possible with MSVC. I guess that you can
> > re-use a large part of the NSI scripts I wrote for the MSVC-based
> package.

I very much hoped that this is possible :)

> > It'd be also interesting to do some benchmarking.
> > 
> > Michael.
> > 
> 
> Yes I agree, and hope as much as possible of the MSVC build could be
> re-used. I would really like to see a MinGW binary as well for exactly
> the reason Michael mentions. IE. You can include the compilers..

Yes, this is the point I like about an mingw build - you can provide 
a complete including the compiler

> One of the big issue I had with a mingw binary when I was building them
> a couple of years back was the Atlas libraries (I couldn't build them
> under vmware) and the ginac/cln dependencies of the symbolic package. In
> fact getting all of the dependencies built is as big an issue (if not
> bigger) than building Octave itself. I believe that the Altas 3.7.33 is
> almost a release candidate for 3.8.0 and that it includes a build
> process for particular architectures, and so might be easier to build
> than the 3.6.0 atlas was.

Yep, I have not succeeded builting atlas 3.6.0 yet, I used a reference
blas/lapack as first step.
I'll try atlas again using the cygwin framework, but mingw compilers, 
let's see if this works. I did't check the 3.7.33, if 3.8 is released
it's surely worth a try.
 
> The additional questions I'd ask are
> 
> * Do you have a build script for Octave and all its dependencies? I have
> one that is almost two years old now so is very out of date

Not a single script (yet). As you said, building the dependencies is
actually more work than building octave. I kow did it piecewise, like
work in progress, not everything in one step.
But this should in principle be possible to create. 

> * Do you have an installer? Probably NSIS based?

Not yet. I counted on being able to reuse Michael's NSIS scripts. 
This should be possible given that the directory structure of the binary
and dependencies is practically the same.
I have not worked with nsis yet, but i guess it's not that hard to learn...

> * Is there someway to use Michael's build process for MinGW as well? In
> fact could the build process be made compatible with both?

What do you mean by "build process" ?
Every dependency at least comes with a makefile, so building them is 
a matter of configure and/or make.
The Octave build process uses the configure&make procedure as-is.

> * Are you willing to support the continued building of mingw binaries?
> The person who built the last cygwin binary on octave-forge did it once
> then disappeared. However, if the MSVC build process might be shared
> between MSVC and MinGW then this might be less of an issue.

Yes, provided that it's clear that this will not be my full-time job.
I see also a big overlap between mingw and msvc build, so there
will be synergies.

> Looking at Michael's notes in octave-forge/admin/Windows/msvc I don't
> think he has an automatic build process for all of Octave and its
> dependencies, though it appears he does for octave-forge.

The octave forge packages I built with octave's package manager mechanism
and this worked for the packaged I checked so far.

In fact I relied quite a bit on the work already done by Michael with
the nice documentation on the msvc build process in octave-forge.
So in principle my steps taken are similar to his.
One advantage is that mingw provides a fortran compiler, so I could 
skip the use of f2c.

I have currently built:
blas/lapack 3.1.1: reference build from source (not optimized)
fftw3 3.1.2: built from source
glob (version?): built from the sources hosted by David
glpk 4.9: built from source
gsl 1.9: built from source
hdf5 1.6.5: built from source - this one gave me quite a headache...
pcre 7.0: built from source
readline 5.2: built from source with michael's patch on forge, this one 
I actually built partly using cygwin's gcc due to a bug in mingw's gcc...
Suitesparse 2.4.0: built from source
zlib 1.2.3: built from source
regex: Here I took the regec-spencer library from gnuwin32
(did I miss something?)
All dependencies built as dlls, or created dlls from the static libs

I have also used Michael's c++ code of mkoctfile and octave-config from
forge (slightly modified) instead of the shell scripts.

What I have not yet tried is
Octplot - simply not used yet
gnuplot - here I used the win32 binaray available
Don't know how complicated these will be along with their dependencies.

I like the way michael documented his steps in the msvc build, I would
like to have something similar also for the mingw32 build.

As micheal can probably tell, some problems arise in many small details,
and I created work-arounds to succeed a build. My current results are 
not yet that professional to be immediately released, I did not expect 
such quick positive response :)

benjamin

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger