[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mingw32 compiled binaries
From: |
David Bateman |
Subject: |
Re: Mingw32 compiled binaries |
Date: |
Wed, 06 Jun 2007 14:37:32 +0200 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
Benjamin Lindner wrote:
> 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.
I just downloaded and looked at 3.7.33. The timing tests seemed shorter,
but will still probably be an issue with a MinGW build... II
>
>> 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.
Take a look at the script in the mail thread
http://www.nabble.com/Building-Octave-for-Windows-with-MinGW-tf2377593.html#a6633954
which is what I had for MinGW two years ago.
>
>> * 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...
Building first, :-)
>
>> * 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.
Yes, but that involves some manual work on the part the packager. I'd
thought of a script that
* downloads if necessary
* patches
* configures
* makes
* installs
each package with the minimum work on the part of the packager.
>
>> * 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.
That's all we can ask...
>> 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 :)
In fact its those workarounds that any build script would embody... I
think a MinGW build is something that for a long time has been a desire
of many of us.. I know I put quite an effort into a few years back.
Cheers
David
>
> benjamin
>
- Re: Mingw32 compiled binaries, (continued)
- Re: Mingw32 compiled binaries, David Bateman, 2007/06/06
- Re: Mingw32 compiled binaries, Benjamin Lindner, 2007/06/06
- Re: Mingw32 compiled binaries, Michael Goffioul, 2007/06/06
- Re: Mingw32 compiled binaries, Benjamin Lindner, 2007/06/06
- Re: Mingw32 compiled binaries, Michael Goffioul, 2007/06/06
- Re: Mingw32 compiled binaries, Benjamin Lindner, 2007/06/06
- Re: Mingw32 compiled binaries, Michael Goffioul, 2007/06/06
- Re: Mingw32 compiled binaries, Benjamin Lindner, 2007/06/06
- Re: Mingw32 compiled binaries, Tatsuro MATSUOKA, 2007/06/06
- Re: Mingw32 compiled binaries, Benjamin Lindner, 2007/06/06
- Re: Mingw32 compiled binaries,
David Bateman <=
- Re: Mingw32 compiled binaries, Benjamin Lindner, 2007/06/06
- Re: Mingw32 compiled binaries, Tatsuro MATSUOKA, 2007/06/06