octave-devel build: munge-texi(22633) malloc: *** error for object 0x1000d47e0: pointer being freed was not allocated

[vic@…]

Running OSX 10.8.1. I had "octave-devel +docs +fltk" @3.6.2 installed earlier, but an "upgrade outdated" killed it. My latest attempt at a clean installation failed well into the build stage with the messages

:info:build Undefined symbols for architecture x86_64:
:info:build   "std::_List_node_base::_M_transfer(std::_List_node_base*, std::_List_node_base*)", referenced from:
:info:build       std::list<regexp::match_element, std::allocator<regexp::match_element> >::operator=(std::list<regexp::match_element, std::allocator<regexp::match_element> > const&) in liboctave_la-regexp.o
:info:build   "std::_List_node_base::_M_hook(std::_List_node_base*)", referenced from:
:info:build       dir_entry::read()     in liboctave_la-dir-ops.o
:info:build       regexp::match(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in liboctave_la-regexp.o
:info:build       std::list<regexp::match_element, std::allocator<regexp::match_element> >::operator=(std::list<regexp::match_element, std::allocator<regexp::match_element> > const&) in liboctave_la-regexp.o
:info:build   "std::_List_node_base::_M_unhook()", referenced from:
:info:build       std::list<regexp::match_element, std::allocator<regexp::match_element> >::operator=(std::list<regexp::match_element, std::allocator<regexp::match_element> > const&) in liboctave_la-regexp.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build collect2: ld returned 1 exit status
:info:build make[3]: *** [liboctave.la] Error 1

I am attaching the log file

[todmorrison (Tod Morrison)]

Cc Me!

[lawrence.ong@…]

Cc Me!

[gnw3]

Cc Me!

[onurdomanic@…]

Cc Me!

[zabbarob@…]

I get a similar error for: sudo port install octave
(OSX 10.8.1, clean install of MacPorts as described on ​https://trac.macports.org/wiki/Migration after upgrading from Snow Leopard to Mountain Lion)

:info:build Undefined symbols for architecture x86_64:
:info:build   "std::_List_node_base::_M_hook(std::_List_node_base*)", referenced from:
:info:build       dir_entry::read()     in dir-ops.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build collect2: ld returned 1 exit status
:info:build make[2]: *** [liboctave.dylib] Error 1

[todmorrison (Tod Morrison)]

I suspect this is related to ​35770.

[zabbarob@…]

Cc Me!

[gnw3]

I use some software from NASA (SeaDAS) that is built using Apple gcc and g++ with gfortran-4.5. Following this example, I built octave-3.6.2 standalone on Snow Leopard with the same compilers. To get configure to work I had to make a symlink for libstdc++.dylib (e.g., without the ".6") in /opt/local/lib/gcc45.

"make check" passes and things generally seem to work, so I'm now working on a Portfile for this configuration (see attached). Macports adds "-arch x86_64" to the LDFLAGS, so at present the portfile requires a simple wrapper, "octf77-4.N" that replaces the "-arch x86_64" with "-m64". I've tested this on two systems with different atlas builds (one using gcc45 and the other using gcc47). The wrapper I used is just:

$ cat $(which octf77-4.7)
#! /bin/bash
# wrapper for /opt/local/bin/gfortran-mp-4.7 to replace
#   "-arch x86_64" with "-m64"
args="$(echo $@ | sed -e 's/ -arch x86_64 / -m64 /')"
#echo args: $args
exec /opt/local/bin/gfortran-mp-4.7 $args

[gnw3]

test version of Portfile mixing Apple with GNU compilers

[vic@…]

The recent upgrade of gcc45 appears to cure the undefined symbols problem. Now, however, the octave-devel build seems to fail with a malloc error. Here are 28 lines from line # 8996 of the log file. This is where the build breaks down. The complete log, main.2.log, is attached.

:info:build ../../run-octave -f -q -H ./mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS || { rm -f doc-cache; exit 1; }
:info:build octave(77220,0x7fff7e7e9180) malloc: *** error for object 0x104db07c0: pointer being freed was not allocated
:info:build *** set a breakpoint in malloc_error_break to debug
:info:build /bin/sh: line 1: 77220 Abort trap: 6           ../../run-octave -f -q -H ./mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS
:info:build make[3]: *** [doc-cache] Error 1
:info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave-devel/octave-devel/work/octave-3.6.2/doc/interpreter'
:info:build make[2]: *** [all-recursive] Error 1
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave-devel/octave-devel/work/octave-3.6.2/doc'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave-devel/octave-devel/work/octave-3.6.2'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave-devel/octave-devel/work/octave-3.6.2'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave-devel/octave-devel/work/octave-3.6.2" && /usr/bin/make -j4 -w all LANG="C" 
:info:build Exit code: 2
:error:build org.macports.build for port octave-devel returned: command execution failed
:debug:build Error code: CHILDSTATUS 28088 2
:debug:build Backtrace: command execution failed
    while executing
"system -nice 0 $fullcmdstring"
    ("eval" body line 1)
    invoked from within
"eval system $notty $nice \$fullcmdstring"
    invoked from within
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: targets not executed for octave-devel: org.macports.activate org.macports.build org.macports.destroot org.macports.install

[michaelld (Michael Dickens)]

I've just upgraded my gcc47 (et.al.; hopefully), and I'm starting to build octave-devel. My current advice for the malloc error is to try uninstalling (forced) libstdcxx and gcc4X (gcc45 for the above) and reinstalling them, clean out octave-devel, then try installing it again. It'll take a while, but that might work -- I haven't seen rev-bumps in gcc4X ports, which might be required to get the new gcc changes they're making in place (or, might not; I'm no gcc expert).

[michaelld (Michael Dickens)]

gnwiii: Will you post the "svn diff" of that Portfile? I think very little has changed in your version, but it's difficult for me to see (and, I'm building octave-devel right now, so I'm not going to swap that Portfile in an "svn diff" myself).

[vic@…]

Replying to michaelld@…:

I've just upgraded my gcc47 (et.al.; hopefully), and I'm starting to build octave-devel. My current advice for the malloc error is to try uninstalling (forced) libstdcxx and gcc4X (gcc45 for the above) and reinstalling them, clean out octave-devel, then try installing it again. It'll take a while, but that might work -- I haven't seen rev-bumps in gcc4X ports, which might be required to get the new gcc changes they're making in place (or, might not; I'm no gcc expert).

Thanks for the advice, Michael. I think I'll hold off on the uninstalling for a while. Both libstdcxx and gcc45 were updated on my system this morning---and that took quite a while. Apparently this stuff is still changing 35770.

[michaelld (Michael Dickens)]

octave-devel compiles for me now (with the latest gcc changes this morning; I'm using gcc47), but octave doesn't execute:

% octave
GNU Octave, version 3.6.2
Copyright (C) 2012 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.

Octave was configured for "x86_64-apple-darwin12.1.0".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.

For information about changes from previous versions, type `news'.

dyld: lazy symbol binding failed: Symbol not found: ___emutls_get_address
  Referenced from: /opt/local/lib/libstdc++.6.dylib
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___emutls_get_address
  Referenced from: /opt/local/lib/libstdc++.6.dylib
  Expected in: /usr/lib/libSystem.B.dylib

"emutls_get_address" does not exist in that libstdc++ or any of the libraries it references (via "otool -L"). It does exist in "/opt/local/lib/gcc47/libgcc_s.1.dylib", but that library is listed last in the list for the octave executable (and, well after /opt/local/lib/libstdc++.6.dylib). Methinks the gcc port files still have some work to do ... but, I'm going to uninstall and install the gcc47 ports, yet again, to see if maybe it's still my issue (yes, they do take quite a while to build; sigh).

[gnw3]

Replying to michaelld@…:

gnwiii: Will you post the "svn diff" of that Portfile? I think very little has changed in your version, but it's difficult for me to see (and, I'm building octave-devel right now, so I'm not going to swap that Portfile in an "svn diff" myself).

Sorry, I use tarballs here due to firewall issues. I'm using the test Portfile in a private ports tree. I just took a copy of the math/octave-devel directory and edited the Portfile to replace gcc with gfortran pretty much everywhere (to make it clear that only gfortran is used from macports) and then replaced the configure.compiler line:

<     configure.compiler   macports-gcc-${gcc_version}
---
>     configure.cc            llvm-gcc-4.2
>     configure.cxx           llvm-g++-4.2
>     configure.f77           "/usr/local/bin/octf77-${gfortran_version}"

[gnw3]

Replying to vic@…:

The recent upgrade of gcc45 appears to cure the undefined symbols problem. Now, however, the octave-devel build seems to fail with a malloc error.

I did the updates (Snow Leopard), to get:

$ port installed gcc45 atlas libstdcxx
The following ports are currently installed:
  atlas @3.10.0_0+gcc45 (active)
  gcc45 @4.5.4_4+universal (active)
  libstdcxx @4.7.1_100+universal (active)

and tried building octave-devel. The build failed, also with a malloc error, but in a different program:

:info:build ./munge-texi ../.. ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS < preface.txi > preface.texi-t
:info:build munge-texi(22633) malloc: *** error for object 0x1000d47e0: pointer being freed was not allocated
:info:build *** set a breakpoint in malloc_error_break to debug
:info:build /bin/sh: line 1: 22633 Abort trap              ./munge-texi ../.. ..

[michaelld (Michael Dickens)]

OK; I understand the Portfile changes. Interesting idea. There are folks who would want to use newer gcc since it provides better / more efficient assembly code; but, I can see the attractiveness of using a stable / known compiler for the C and C++ codes. Thus, let me get the current version working, then I'll try your variant.

[michaelld (Michael Dickens)]

I'm re-building libstdcxx and gcc47 right now, yet again, to see if maybe the changes of this morning didn't get in place when I did an "upgrade". What a PITA.

[jeremyhu (Jeremy Huddleston Sequoia)]

That malloc error is almost certainly not caused by libstdcxx changes. Try using guardmalloc(3) and malloc_history(1) to find the issue.

[gnw3]

Replying to michaelld@…:

I'm re-building libstdcxx and gcc47 right now, yet again, to see if maybe the changes of this morning didn't get in place when I did an "upgrade". What a PITA.

I got the same errors, so I doubt rebuilding will help. What does seem to work is to use the Apple gcc and g++ compilers with gfortran-mp-4.5

[michaelld (Michael Dickens)]

Replying to jeremyhu@…:

That malloc error is almost certainly not caused by libstdcxx changes. Try using guardmalloc(3) and malloc_history(1) to find the issue.

Well, maybe or not. What I can say is that before the latest GCC stuff, octave-devel worked just fine building and executing. After the GCC changes, we're struggling to build it, or it does not execute if it does build. The Octave source itself did not change; nor did its Portfile. The only thing that has changed in the past few days is the GCC dependency. I do not know if it is libstdcxx or gcc that's the issue, or maybe some combination; but, I highly doubt it's octave itself. If my latest rebuild doesn't work, I'll try using the mixed Apple gcc/g++ and MacPorts fortran approach.

[mf2k (Frank Schima)]

FYI, I installed octave-devel and I see exactly what michaelld posted in comment:14.

[michaelld (Michael Dickens)]

I just reinstalled libstdcxx, gcc47, then octave-devel. Same issue as in comment:14. I'm now going to try the mixed version suggested above.

[michaelld (Michael Dickens)]

GNU libtool also changed, and it is used extensively by octave for compiling. I'll retry building octave-devel with the old libtool and see what happens.

[michaelld (Michael Dickens)]

Reverting GNU libtool (back to 2.4.2_2) changes nothing; still the same issues. So, now I'm really going to try the mixed compiler version.

[michaelld (Michael Dickens)]

gnwiii : It looks like you're using fortran installed somewhere other than MacPorts. Apple does not provided such a program. Do you know where this fortran came from? I really cannot test this change without either using what Apple or MacPorts provides. Using MacPorts' gfortran from gcc47, surprise surprise, results in the same runtime issue.

[gnw3]

Replying to michaelld@…:

gnwiii : It looks like you're using fortran installed somewhere other than MacPorts. Apple does not provided such a program. Do you know where this fortran came from? I really cannot test this change without either using what Apple or MacPorts provides. Using MacPorts' gfortran from gcc47, surprise surprise, results in the same runtime issue.

I'm using macports gfortran-mp-4.x (both 4.5 and 4.7 seem to work). macports adds '-arch x86_64' to the list of flags, so I use a trivial wrapper script called "/usr/local/bin/octf77-4.5", etc. The wrapper (listed in a previous post to this thread) just runs gfortran-mp-4.x after editing the arg list to change ' -arch x86_64 ' to ' -m64 ' with sed (fragile, but good enough to build octave).

[jrhope]

Cc Me!

[michaelld (Michael Dickens)]

gnwiii : Ah; sorry I missed your posting of that script. I'll try it out tomorrow first thing. Thanks for being patient.

[jeremyhu (Jeremy Huddleston Sequoia)]

The comment #14 issue is a dupe of #36093

Regarding the malloc issue, from my email just now to macports-dev:

Thanks for pointing out that --enable-fully-dynamic-string issue. It's not actually the case that you think (incompatibility with the host). The problem seems to be that some of MacPorts' gcc compilers have been built with --enable-fully-dynamic-string and others haven't. gcc44 and gcc45 are built with --enable-fully-dynamic-string and gcc46, gcc47, and gcc48 aren't, so gcc44 and gcc45 aren't compatible with the libstdcxx that is built from gcc47 because of this difference.

I think we should try having users experiencing issues with octave-devel using gcc44 and gcc45 rebuild the compiler without --enable-fully-dynamic-string to see if that solves that particular issue...

[jeremyhu (Jeremy Huddleston Sequoia)]

Please try the new libstdcxx from r97744 and gcc44 from r97745

[jeremyhu (Jeremy Huddleston Sequoia)]

I was able to build octave-devel +gcc47 just fine (after these changes) ... trying +gcc44 now...

[gnw3]

Replying to michaelld@…:

gnwiii : Ah; sorry I missed your posting of that script. I'll try it out tomorrow first thing. Thanks for being patient.

No problem -- it has been a hectic week so hard to keep up. Looks like the source of the malloc problem has been identified and addressed in updates to gcc44 and gcc45. I'm still thinking it would be nice if macports had the option of using Apple C and C++ with macports gfortran or (even the Xcode compatible gfortran from the R-project) for octave, R, and other big systems that require Fortran. I'm going to try building octave with the R-project's gfortran:

 gfortran-4.2 --version
GNU Fortran (GCC) 4.2.1 (Apple Inc. build 5664)

This compiler understands -arch .., which would simplify the Portfile. Unfortunately, there are old attempts using this compiler that failed on make check so some additional patches (or perhaps a newer octave version) will be required.

[vic@…]

I just did a clean installation of octave-devel:

   sudo port install octave-devel +gcc47 +docs +fltk

The build went perfectly and octave now works---but with one serious problem that is announced immediately:

warning: no graphical display found

The latest port of aquaterm @1.1.1 is installed and active in my MacPorts system. I believe octave-devel should have picked this up during its compilation.

[jeremyhu (Jeremy Huddleston Sequoia)]

octave-devel +gcc44 also built fine.

vic, please open a new ticket for your graphics issue