Re: README.MacOS

[Jarno Rajahalme]

Lucas,

I tried out the address@hidden from macports, with the port "-k" option, so 
that the build files are not removed. Doing "sudo make check" on the build 
directory gave 52 test failures, in very strange places. For example, 
str2double("1") returns NaN, etc:

:octave-3.3.90 $ sudo make check | grep FAIL
  src/DLD-FUNCTIONS/dlmread.cc ........................... PASS    4/20   FAIL 
16
  src/DLD-FUNCTIONS/regexp.cc ............................ PASS   78/85   FAIL 7
  src/DLD-FUNCTIONS/str2double.cc ........................ PASS   10/20   FAIL 
10
  src/mappers.cc ......................................... PASS  267/268  FAIL 1
  src/ov-fcn-handle.cc ................................... PASS    2/3    FAIL 1
  scripts/io/strread.m ................................... PASS    1/7    FAIL 6
  scripts/io/textscan.m .................................. PASS    0/2    FAIL 2
  test_io.m .............................................. PASS   65/68   FAIL 3
  test_prefer.m .......................................... PASS   26/29   FAIL 3
  test_sparse.m .......................................... PASS 1202/1204 FAIL 2
  test_system.m .......................................... PASS   94/95   FAIL 1
  FAIL     52

I did a local copy of the Portfile, and applied the change I proposed below 
(LDFLAGS) (as well as removing a lo-specfun.cc patch that is no more needed). 
After "portindex" and new install, "sudo make check" (in the new build 
directory) gives 2 FAILs. First of them is known, due to how Apple interprets 
PI rounding rules for single precision floats, and other just because I had to 
run the check under sudo. In other words, 50 weird failures went away:

:octave-3.3.90 $ sudo make check | grep FAIL
  src/mappers.cc ......................................... PASS  267/268  FAIL 1
  test_system.m .......................................... PASS   94/95   FAIL 1
  FAIL      2
MacJr:octave-3.3.9

Have a try with the following patch to the octave-devel Portfile.

My understanding and experience is that somehow the libstdc++ calls get mixed 
up between the system version and the compiler version without the patch. Both 
have to be linked in, unless all the relevant system libraries could be linked 
again. When this hits malloc/free, octave segfaults. Now it is only getting 
incorrect results in string functions etc. Having the the compiler version of 
the libstdc++ first on the link line ensures that all unresolved references to 
the libstdc++ get resolved to the same library, and to the one the compiler is 
expecting to be used.

Note that due to the path in the LDFLAGS, this works only as a gcc45 variant. 
This change should be made sensitive to the chosen variant (gcc version). If 
you find this helpful, feel free to push this to macports.

  Jarno


*** 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/math/octave-devel/Portfile
 Tue Jan 25 04:00:14 2011
--- ports/math/octave-devel/Portfile    Tue Jan 25 13:52:33 2011
***************
*** 58,67 ****
  # flag, which means this port cannot easy compile as universal.
  patchfiles-append patch-configure.diff
  
! platform darwin 10 {
!     # for 10.6 only
!     patchfiles-append patch-lo-specfun.cc.diff
! }
  
  universal_variant   no
  
--- 58,67 ----
  # flag, which means this port cannot easy compile as universal.
  patchfiles-append patch-configure.diff
  
! #platform darwin 10 {
! #    # for 10.6 only
! #    patchfiles-append patch-lo-specfun.cc.diff
! #}
  
  universal_variant   no
  
***************
*** 111,117 ****
  configure.env-append SED="${prefix}/bin/gsed" \
                       TEXI2DVI="${prefix}/bin/texi2dvi" \
                       TEXI2PDF="${prefix}/bin/texi2pdf" \
!                      FLTK_CONFIG=no
  
  ### parallel build is supposed to work now
  # use_parallel_build  no
--- 111,118 ----
  configure.env-append SED="${prefix}/bin/gsed" \
                       TEXI2DVI="${prefix}/bin/texi2dvi" \
                       TEXI2PDF="${prefix}/bin/texi2pdf" \
!                      FLTK_CONFIG=no \
!                      LDFLAGS="${prefix}/lib/gcc45/libstdc++.6.dylib"
  
  ### parallel build is supposed to work now
  # use_parallel_build  no



On Jan 24, 2011, at 14:37 , ext Lukas Reichlin wrote:

> 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
> 
> 
> On 24.01.2011, at 11:56, Jarno Rajahalme wrote:
> 
>> 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
>> 
>> 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
>> 
>