Re: README.MacOS

[Ben Abbott]

On Jan 25, 2011, at 10:35 AM, Jarno Rajahalme wrote:
> 
> On Jan 24, 2011, at 14:37 , ext Lukas Reichlin wrote:
> 
>> On 24.01.2011, at 11:56, Jarno Rajahalme wrote:
>>> 
>>> On Jan 24, 2011, at 9:51 , ext John W. Eaton wrote:
>>> 
>>>> On 23-Jan-2011, Ben Abbott wrote:
>>>> 
>>>> | I've edited the README.MacOS file to include instructions on using 
>>>> MacPorts.
>>>> | 
>>>> | I'm not a MacPorts user so I may have some things wrong.
>>>> | 
>>>> | Corrections and/or constructive critique would be appreciated.
>>>> 
>>>> | 1. General Users
>>>> | ================
>>>> | 
>>>> | A MacOS bundle is available from sourceforge.
>>>> | 
>>>> |   http://octave.sourceforge.net/index.html
>>>> | 
>>>> | There are also Octave packages available from both Fink and MacPorts.  
>>>> Each
>>>> | of these package managers handle the details of compiling Octave from 
>>>> source.
>>>> | 
>>>> |   http://www.finkproject.com
>>>> |   http://www.macports.org/
>>>> 
>>>> Users might also want to build from source for various reasons.  They
>>>> will probably want to build using a stable release rather than using
>>>> the sources from the Mercurial archive.  So you might rename this
>>>> first section "Easy to install Binary Releases" (or similar) and the
>>>> section for Developers could be renamed "Building from Source" and
>>>> then explain where and how to get the sources from Mercurial (you
>>>> could just point to the instructions on savannah) and also that stable
>>>> releases are availble from ftp.gnu.org in the directory
>>>> pub/gnu/octave.  Then I think the only difference in the directions
>>>> would be that once you've got the sources you should skip the
>>>> autogen.sh step if you are building from sources downloaded in a tar
>>>> file.
>>>> 
>>>> jwe
>>> 
>>> I have been building Octave from sources on OSX using GCC 4.5. To avoid 
>>> crashes LDFLAGS needs to have the newer libstdc++ as the first file to be 
>>> linked with, like:
>>> 
>>> export LDFLAGS="/opt/local/lib/gcc45/libstdc++.6.dylib"
>>> 
>>> (Above before ./configure)
>>> 
>>> Without this Octave segfaults when compiled with newer-than-Apple GCC.
>>> 
>>> Also, Apple blas (vecLib) does not work with 64-bit gfortran (4.2, 4.3, 
>>> 4.4, nor 4.5). Complex functions obviously fail (and segment fault) without 
>>> -ff2c option, but then other non-complex routines return incorrect answers 
>>> when -ff2c is enabled, so that configure fails. So with 64-bit OSX you 
>>> pretty much have to use atlas and/or lapack.
>>> 
>>> Would information like this be of interest in README.MacOS?
>>> 
>>> Jarno
>>> 
>> Hi Jarno
>> 
>> Your information is exactly what I've been looking for!  I'm working on a 
>> new control package based on a Fortran library and I have exactly the 
>> problem you describe (vecLib).  There's an octave bug report [1] as well as 
>> a MacPorts ticket [2] for octave-devel 3.3.90.  May I ask you to have a look 
>> at it?  I would be very happy if you could give us some advice.
>> 
>> Best Regards,
>> Lukas
>> 
>> [1]
>> https://savannah.gnu.org/bugs/?32009
>> 
>> [2]
>> https://trac.macports.org/ticket/27980#comment:13
> 
> I just checked the status of my bug report with Apple regarding 64-bit BLAS. 
> It is still open and unresolved. I also redid my check to confirm that the 
> problem still exists. My test case is online at: 
> http://www.macresearch.org/lapackblas-fortran-106#comment-17217
> 
> Maybe the README.MacOS should state that:
> 
> "As of OSX 10.6.6, blas (a part of Framework Accelerate) is not working 
> correctly in 64-bit mode. Alternative blas library (such as ATLAS) has to be 
> used for 64-bit builds."
> 
> You may also want to add a reference to 
> http://www.macresearch.org/lapackblas-fortran-106#comment-17217 , so that the 
> presence of this bug can be verified with later OSX versions.
> 
>  Jarno

Jarno/Lukas, pls respond at the *bottom* of the email thread, as it makes it 
much easier for those arriving late to follow along. Thanks!

Jarno, is MacResearch a part of Apple?

Ben