Re: Relocatable octave

[Thomas Treichl]

Paul Kienzle schrieb:
> On May 28, 2007, at 5:15 PM, Thomas Treichl wrote: 
> > Paul Kienzle schrieb:
> > > >  and 2nd because other users must not have installed the same 
> > > > macports compilers than me - this would mean that the mkoctfile 
> > > > shell script must be changed by hand). Shipping the same compilers 
> > > > with the octave.dmg wouldn't make sense, because then the octave.dmg 
> > > > grows from 70MB to > 200MB.
> > > This problem is more difficult.  I'm hoping you can use the default 
> > > C/C++ compiler and just ship your own version of the fortran compiler.
> >
> > I can use the default gcc now and gfortran from the link you've sent. 
> > Together they are doing a good job. I actually don't want to ship just 
> > a gfortran with the octave.app but further tell the users where to get 
> > that one needed in a seperate *html file.
>
> Your call.

No, let's talk about it. You clearly summarized pro and contras in this email 
and now I'd like to know what the best solution would be. Sure, the best 
solution would be if Apple brings the gfortran compiler with the whole gcc-suite 
- that's no question. The problem is that they didn't do (at least for the 
systems that are already out, OSX 10.2.x, 10.3.x, 10.4.x, etc.) - maybe some 
when they will?!

> You have to be sure to supply any dynamic libraries from fortran that 
> you link against because the octave core will require them.  Linking 
> against a static version is questionable practice (something about code 
> not being relocatable on the static version) and I have not fully tested 
> that it works.

Ok, so we should differ between two things:

a) we need to supply the necessary gfortran dylibs for running octave. I think 
(but have not fully tested this) that this is already working with the current 
octave.app.

b) We need a gfortran or g95 or f2c or whatever to further install additional 
packages.

> Another concern is that some folks will already have a fortran compiler 
> installed, and this will not work with the fortran you used.  Asking 
> them to install yours may break their existing software.

On the other side they maybe would like to use their own fortran compiler they 
already have installed because they do know that the one they have installed 
really does work. This is my experience over the last weeks: I downloaded at 
least 5 different binary releases of different gfortran compilers. 3 of 5 didn't 
do a good job, ie. compilation and/or linking of octave failed with the gcc 
4.0.1 that already is on my system.

So if we would say that we supply a gfortran compiler within the octave.app then 
how can we make sure that this gfortran works perfectly with the installed gcc 
on the user's Mac? What if somebody doesn't use XCode 2.4.1 but eg. (maybe) 
2.2.x that comes with (don't know) gcc 3.3 - gfortran and gcc 3.2 might this be 
working?

I'd really like do have an answer for this issue but at the moment I don't have. 
And I won't supply another gfortran that maybe doesn't work, there are already 
enough not-working fortran binaries out there at WWW - just wanted to make sure 
that it's not because of 16MB more disk size.

> Regardless of how you resolve these issues, please make sure the fortran 
> compiler is available from the same site as octave --- if the site you 
> link to upgrades their fortran compiler your package may stop working.  
> This happened to me with AquaTerm and GnuPlot being out of sync.
>
>     - Paul

And where could this site be? Would sourceforge welcome hosting another fortran 
binary release?

- Thomas