MinGW build of octave

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

MinGW build of octave

David Bateman-3
Dear All,

As I've mentioned on the lists I've been looking at a MinGW build of
octave, and now have something that I think is good enough to share with
others. You'll need to recover the two files from
http://www.dbateman.org/octave, then follow the instructions below,
adpated to your own preferences and existing setup.

Reference [1] http://www.mingw.org/download.shtml

* Download MinGW-4.1.0.exe and use it to install compilers (using 3.4.2
personally)
* Download MSYS-1.0.10.exe and install minimal environment (install in
c:\msys)
* Download msyDTK-1.0.1.exe and instal it for autoconf, etc (install in  
c:\msys)
* Use the wget mingwPort package to install wget (Warning binary version
of wget supplied with package seems broken, and so you must download the
source of wget by hand at the same location)
* Use zlib mingwPort package, which can be download since built version
of wget works
* Go to the www.activestate.com page and install msi version of
ActivePerl (I'm not sure that this step is now necessary with msysDTK as
msysDTK also has  perl, but haven't checked)
* Use my own readline 5.0 mingwPort package to install readline
libraries from http://www.dbateman.org/octave/readline-5.0-mingwPORT.tar.bz2
* Get ftp://ftp.gnuplot.info/pub/gnuplot/gp400win32.zip and unzip under c:\
* Now you can build octave
  - Download version 2.9.3 or later of octave
  - untar and apply supplied patch from
http://www.dbateman.org/octave/patch-mingw-2.9.3.gz
  - Use autogen.sh to rebuild configure, etc
  - export PATH=$PATH:/c/gnuplot/bin
  - configure --prefix=/mingw/octave-2.9
  - make
  - make install-strip
* cmd.exe
 
PATH=%PATH%;C:\MinGW\bin;C:\msys\bin;C:\MinGW\octave-2.9\bin;C:\gnuplot\bin
  octave

Note, don't use msys rxvt to launch octave.. The pty emulation in msys
rxvt is seriously broken and readline will therefore not work correctly.
Cygwin rxvt seems fine but implies that you must have cygwin installed,
which kind of misses the point of a mingw build. So use cmd.exe by
preference. I presume someone will want to write an IDE under windows in
the long run in any case and so redirecting stdout/stdin from a console
app will avoid this issue.

Also note the fork issues with mingw were not an issue, perhaps due to
the version of gcc I used having rmdir, mkdir and rename defined, and so
liboctave/{rmdir.c,mkdir.c,rename.c} were ifdef'ed out.. However this
means that Ffork won't work in the mingw build. The cost of including an
implementation of fork basically means that all of the code in cygwin
fork.cc needs to be included in octave (or probably mingw) this is also
seems unlikely, so Ffork will probably never be implemented in mingw.

I'm not completely happy with the patch yet as it has one remaining
issue in that ctrl-c at the prompt is not working correctly (though is
elsewhere). Note that I also had to reinclude the glob directory in
octave as this is missing in the mingw/msys stuff. Problems that I know
I have fixed include

- readline works in cmd.exe
- ctrl-c works except at the prompt (take Paul Kienzle for the help)
- Loadable modules (ie octfiles)
- Path seperator issues that were preventing octave finding its scripts.
Path seperator is now ";" under mingw rather than ":" elsewhere.
- a problem with popen's use in help (ie passed /dev/null) that prevent
texinfo help from working
- install issues due to the lack of ln that was preventing a full
install, in particular of the libraries and oct-files
- Saving of .octave_hist file now happens in %HOMEPATH% if %HOME% isn't
defined, same for .octaverc
- Some issues of \r\n in the documentation fixed-up (is this completely
resolved? Do we care if the docs are already build.. WARNING 2.9.3 has
some timestamps of some *.txi that force rebuild!!)

I haven't extensively tested the patch, but I did test the script in the
g++ sjlj/dwarf2 bug report that is causing the speed issues before
embarking on this effort and demonstrated that a mingw build did no have
the speed issues. So I expect this build of octave to be significantly
faster than the cygwin builds. As this stuff will take a while to
finalize I'm also working against 2.9.3 (note not the CVS, but will
upgrade at next 2.9 release), and have no intention of porting this to
the 2.1.x tree.

Next steps include fixing the ctrl-c issue at the prompt, and starting
to port such libraries as fftw, atlas, gplk, hdf5, umfpack, etc for use
by octave. Finally building the relevant stuff from octave-forge and
their support libraries, should also be done. Once that is done we can
look at using the NSIS installer that Paul has been working on in
octave-forge to build a simple install for windows users. If anyone
wants to try this stuff out, I'd love to get some feedback.

Regards
David

--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

Reply | Threaded
Open this post in threaded view
|

RE: MinGW build of octave

Paul Billings
David,

Forgive me for being a nOOb, buy why are you working so hard to get cygwin
going under mingw?  It can't be the sjlj-speed-issue since rebuilding
cygwin's gcc is easier.  I am sure I am missing something.

Paul


> -----Original Message-----
> From: David Bateman [mailto:[hidden email]]
> Sent: Thursday, August 11, 2005 6:05 AM
> To: octave maintainers mailing list
> Subject: MinGW build of octave
>
>
> Dear All,
>
> As I've mentioned on the lists I've been looking at a MinGW build of
> octave, and now have something that I think is good enough to share with
> others. You'll need to recover the two files from
> http://www.dbateman.org/octave, then follow the instructions below,
> adpated to your own preferences and existing setup.
>
> Reference [1] http://www.mingw.org/download.shtml
>
> * Download MinGW-4.1.0.exe and use it to install compilers (using 3.4.2
> personally)
> * Download MSYS-1.0.10.exe and install minimal environment (install in
> c:\msys)
> * Download msyDTK-1.0.1.exe and instal it for autoconf, etc (install in
> c:\msys)
> * Use the wget mingwPort package to install wget (Warning binary version
> of wget supplied with package seems broken, and so you must download the
> source of wget by hand at the same location)
> * Use zlib mingwPort package, which can be download since built version
> of wget works
> * Go to the www.activestate.com page and install msi version of
> ActivePerl (I'm not sure that this step is now necessary with msysDTK as
> msysDTK also has  perl, but haven't checked)
> * Use my own readline 5.0 mingwPort package to install readline
> libraries from
> http://www.dbateman.org/octave/readline-5.0-mingwPORT.tar.bz2
> * Get ftp://ftp.gnuplot.info/pub/gnuplot/gp400win32.zip and unzip
> under c:\
> * Now you can build octave
>   - Download version 2.9.3 or later of octave
>   - untar and apply supplied patch from
> http://www.dbateman.org/octave/patch-mingw-2.9.3.gz
>   - Use autogen.sh to rebuild configure, etc
>   - export PATH=$PATH:/c/gnuplot/bin
>   - configure --prefix=/mingw/octave-2.9
>   - make
>   - make install-strip
> * cmd.exe
>
> PATH=%PATH%;C:\MinGW\bin;C:\msys\bin;C:\MinGW\octave-2.9\bin;C:\gn
> uplot\bin
>   octave
>
> Note, don't use msys rxvt to launch octave.. The pty emulation in msys
> rxvt is seriously broken and readline will therefore not work correctly.
> Cygwin rxvt seems fine but implies that you must have cygwin installed,
> which kind of misses the point of a mingw build. So use cmd.exe by
> preference. I presume someone will want to write an IDE under windows in
> the long run in any case and so redirecting stdout/stdin from a console
> app will avoid this issue.
>
> Also note the fork issues with mingw were not an issue, perhaps due to
> the version of gcc I used having rmdir, mkdir and rename defined, and so
> liboctave/{rmdir.c,mkdir.c,rename.c} were ifdef'ed out.. However this
> means that Ffork won't work in the mingw build. The cost of including an
> implementation of fork basically means that all of the code in cygwin
> fork.cc needs to be included in octave (or probably mingw) this is also
> seems unlikely, so Ffork will probably never be implemented in mingw.
>
> I'm not completely happy with the patch yet as it has one remaining
> issue in that ctrl-c at the prompt is not working correctly (though is
> elsewhere). Note that I also had to reinclude the glob directory in
> octave as this is missing in the mingw/msys stuff. Problems that I know
> I have fixed include
>
> - readline works in cmd.exe
> - ctrl-c works except at the prompt (take Paul Kienzle for the help)
> - Loadable modules (ie octfiles)
> - Path seperator issues that were preventing octave finding its scripts.
> Path seperator is now ";" under mingw rather than ":" elsewhere.
> - a problem with popen's use in help (ie passed /dev/null) that prevent
> texinfo help from working
> - install issues due to the lack of ln that was preventing a full
> install, in particular of the libraries and oct-files
> - Saving of .octave_hist file now happens in %HOMEPATH% if %HOME% isn't
> defined, same for .octaverc
> - Some issues of \r\n in the documentation fixed-up (is this completely
> resolved? Do we care if the docs are already build.. WARNING 2.9.3 has
> some timestamps of some *.txi that force rebuild!!)
>
> I haven't extensively tested the patch, but I did test the script in the
> g++ sjlj/dwarf2 bug report that is causing the speed issues before
> embarking on this effort and demonstrated that a mingw build did no have
> the speed issues. So I expect this build of octave to be significantly
> faster than the cygwin builds. As this stuff will take a while to
> finalize I'm also working against 2.9.3 (note not the CVS, but will
> upgrade at next 2.9 release), and have no intention of porting this to
> the 2.1.x tree.
>
> Next steps include fixing the ctrl-c issue at the prompt, and starting
> to port such libraries as fftw, atlas, gplk, hdf5, umfpack, etc for use
> by octave. Finally building the relevant stuff from octave-forge and
> their support libraries, should also be done. Once that is done we can
> look at using the NSIS installer that Paul has been working on in
> octave-forge to build a simple install for windows users. If anyone
> wants to try this stuff out, I'd love to get some feedback.
>
> Regards
> David
>
> --
> David Bateman                                [hidden email]
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
> Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
> 91193 Gif-Sur-Yvette FRANCE
>
> The information contained in this communication has been classified as:
>
> [x] General Business Information
> [ ] Motorola Internal Use Only
> [ ] Motorola Confidential Proprietary

Reply | Threaded
Open this post in threaded view
|

Re: MinGW build of octave

David Bateman-3
In reply to this post by David Bateman-3
> Forgive me for being a nOOb, buy why are you working so hard to get cygwin
> going under mingw?  It can't be the sjlj-speed-issue since rebuilding
> cygwin's gcc is easier.  I am sure I am missing something.


MinGW stands for "minimalist Cygwin", and builds binaries that don't
depend on cygwin.dll or in fact any external dlls except those you
specify yourself. So I'm not building cygwin under mingw, but rather a
Windows native version of octave. The cygwin version is most certainly
not native as it depends on symbolic links, its own libraries, etc not
normally available in Windows. So ultimately MinGW is a much better way
to go than cygwin as it contains less cruft.

I also think you are mistaken on the amount of effort to rebuild cygwin
gcc, since you not only have to rebuild cygwin gcc but all of the other
libraries that octave depends on (cygwin.dll included). In fact you
probably should rebuild everything in your cygwin install to avoid dll
hell, with two versions of important libraries... Sorry, if MinGW is
ultimately the better way to go I prefer to avoid that nightmare, and as
an upside also avoid the sjlj slow-ups of cygwin builds with gcc 3.3 and 3.4

Cheers
David

--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

Reply | Threaded
Open this post in threaded view
|

RE: MinGW build of octave

Paul Billings
Less cruft: very often a worthy goal!
Effort for using rebuild gcc: The only difference between the original gcc
and rebuilt gcc is the implementation of exception handling.  Cygwin.dll
does not use C++ exceptions and would therefore not require a rebuild.  That
said, I haven't done it, so I could be all wet, but in theory... ;-)

I better understand the motivation, now -- thanks.  Best of luck toward a
MinGW version!

Paul


> -----Original Message-----
> From: David Bateman [mailto:[hidden email]]
> Sent: Thursday, August 11, 2005 10:04 AM
> To: octave maintainers mailing list
> Subject: Re: MinGW build of octave
>
>
> > Forgive me for being a nOOb, buy why are you working so hard to
> get cygwin
> > going under mingw?  It can't be the sjlj-speed-issue since rebuilding
> > cygwin's gcc is easier.  I am sure I am missing something.
>
>
> MinGW stands for "minimalist Cygwin", and builds binaries that don't
> depend on cygwin.dll or in fact any external dlls except those you
> specify yourself. So I'm not building cygwin under mingw, but rather a
> Windows native version of octave. The cygwin version is most certainly
> not native as it depends on symbolic links, its own libraries, etc not
> normally available in Windows. So ultimately MinGW is a much better way
> to go than cygwin as it contains less cruft.
>
> I also think you are mistaken on the amount of effort to rebuild cygwin
> gcc, since you not only have to rebuild cygwin gcc but all of the other
> libraries that octave depends on (cygwin.dll included). In fact you
> probably should rebuild everything in your cygwin install to avoid dll
> hell, with two versions of important libraries... Sorry, if MinGW is
> ultimately the better way to go I prefer to avoid that nightmare, and as
> an upside also avoid the sjlj slow-ups of cygwin builds with gcc
> 3.3 and 3.4
>
> Cheers
> David
>
> --
> David Bateman                                [hidden email]
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
> Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
> 91193 Gif-Sur-Yvette FRANCE
>
> The information contained in this communication has been classified as:
>
> [x] General Business Information
> [ ] Motorola Internal Use Only
> [ ] Motorola Confidential Proprietary
>