Re: More on OSX build problems

[Jarno Rajahalme]

The malloc problem you see is likely due to your linked binary containing two 
versions of the libstdc++, and in some cases one of them being used to malloc 
and the other to free. This happens when you use non-Apple GCC/G++ to compile 
Octave. To get around this problem you need to add your compiler's version of 
the libstdc++ as the first argument in the LDFLAGS. This is mentioned in the 
etc/README.MacOS as follows (see below), but the text may be a bit misleading, 
as the system's version of libstdc++ gets pulled in in any case, as some of the 
system libraries depend on it, and there is no way to compile those libraries 
again with another compiler.

Excerpt from etc/README.MacOS:

  * The same compiler must be used to build all all of Octave's sources.  This
    is necessary to avoid conflicts between the compiler libraries such as
    libstdc++.  For a successful build the first file in LDFLAGS must refer to
    this library.  For example, if building with gcc-4.5 obtained from MacPorts
    LDFLAGS would begin as,

      export LDFLAGS="/opt/local/lib/gcc45/libstdc++.6.dylib [...]"

Hope this helps,

  Jarno

On Oct 4, 2011, at 11:23 , ext Dr. Alexander Klein wrote:

> Good morning,
> 
> I spent the better part of the weekend tracking the build problems I 
> experience on OSX. I upgraded one of my machines to Snow Leopard, compiled 
> and installed everything in /usr/local/ manually, and then started plodding 
> downwards through Octave's revision tree.
> 
> After dozens of builds I can sum up my results as follows:
> 
> Each revision tagged as "stable" builds, but crashes during make check for as 
> far as I could go back in the revision history without things breaking due to 
> other problems, which begins shortly after the 3.2.4 release and ends around 
> revision 128xy.
> 
> Here's the result from revision 13254, for example:
> 
> make -C test check
> ./build_sparse_tests.sh
> ./build_bc_overload_tests.sh ./bc_overloads_expected
> ../run-octave --norc --silent --no-history ./fntests.m .
> octave(9664) malloc: *** error for object 0x102ecc5c0: pointer being freed 
> was not allocated
> *** set a breakpoint in malloc_error_break to debug
> panic: Abort trap -- stopping myself...
> octave(9664) malloc: *** error for object 0x102ecc5c0: pointer being freed 
> was not allocated
> *** set a breakpoint in malloc_error_break to debug
> panic: attempted clean up apparently failed -- aborting...
> make[1]: *** [check] Abort trap
> make: *** [check] Error 2
> 
> Then again, none of the revisions that are not tagged "stable" showed this 
> behaviour. Revision 13268 builds ok with a few failed tests during make check.
> 
> The one thing I don't get however: If the two revision trees are merged every 
> once in a while as the commit messages suggest, then why aren't behaviours 
> merged, too? I'd expect that after such a point either both would work or 
> both would crash, but this simply isn't the case. What could be the reason 
> for such strange differences in behaviour? Am I missing something?
> 
> I'm really at my wits' end ...
> 
>       Alex
> 
> -- 
>          Dr. Alexander Klein, Diplom-Mathematiker
> 
> Physiologisches Institut       |               TransMIT Zentrum
> Raum 543                       |        für Numerische Methoden
> Aulweg 129                     |          Heinrich-Buff-Ring 44
> 35392 Giessen                  |                  35392 Giessen
>