Re: Successful compilation with MinGW

[Andy Adler]

There are a few remaining technical issues, but they are minor:

- which version to compile? The 2.9.x series has so many advantages
  for me, that I don't want 2.1.72. But, as David said, we should
  wait for 2.9.5 so users can make bug reports against a known version.

- Good performance on windows requires GCC-3.2. Can anyone comment
  on whether 2.9.x compiles against that version of GCC? John recently
  put in a patch so it comples with Gcc-3.3.

- Octave-forge is a jumble right now in terms of 2.9.x support. It
  would require some judgement to choose which parts to include.

- Dynamic linking on windows creates huge binaries, because of
  1) each oct file gets a copy of libstdc++, and 2) the windows
  DLL architecture sucks. Paul Kiezle has posted a solution to #1.

  I would prefer to build octave with all the DLD files linked
  to liboctinterp.so or something like that.

  My windows 2.1.42 binary was quite small (6.4M) because it was
  statically compiled. Maybe this is all that is needed for most
  windows users.

- ATLAS, FFTW, etc support. In my 2.1.42 binary, I provided
  ATLAS for PII, PIV, and Athlon. Is this enough? Should a windows
  binary autodetect the user's processor type?

--
Andy Adler <address@hidden> 1(613)562-5800x6218

On Mon, 9 Jan 2006, Shai Ayal wrote:

> This is surprising!
>
> So, Andy, would it be safe to say that providing an octave installer
> for windows is only a "time" problem -- i.e. someone would have to
> invest the time but there are no "technological" problems? would the
> following procedure work?
>
> 1. get current octave & octave-forge precompiled cygwin packages and
> dependencies
> 2. get current cygwin1.dll and binary edit it to replace "Cygnus
> Solutions" as the registry key.
> 3. gather all other packages (gnuplot etc..) which could be the same
> as in your 2.1.42 package
> 4. slightly modify your NSIS script to account for any changes
> 5. produce a nice octave installer just like window users like. It
> will be self contained and will not affect any preinstalled cygwin
>
> Shai
>
>
>
> On 1/9/06, Andy Adler <address@hidden> wrote:
> > On Mon, 9 Jan 2006, Shai Ayal wrote:
> >
> > > I think that including a cygwin1.dll in a "nice" windows installer is
> > > not that hard. From what I remember, the problem pops up when you
> > > already have another version of the cygwin1.dll installed you get very
> > > bad conflicts since they seem to relay on version independent registry
> > > entries-- i.e. installing octave+cygwin.dll in a system with cygwin
> > > already installed would break the old cygwin installation.
> > >
> > > If we were able to get around this problem, a one-step windows
> > > installer would be possible.
> >
> >
> > It is not hard to write a special cygwin1.dll that does not conflict.
> > The easist way is to binary edit it to replace "Cygnus Solutions" as
> > the registry key.
> >
> > In the 2.1.42 windows version I provided, the reg key was "GNU Octave.
> > http://www.site.uottawa.ca/~adler/octave/index.html
> >
> > --
> > Andy Adler <address@hidden> 1(613)562-5800x6218
> >
>