On Sep 11, 2012, at 13:37, Dan Ports <[email protected]> wrote: > On Tue, Sep 11, 2012 at 03:32:04PM -0400, Michael Dickens wrote: >> I've already had folks writing me that octave (via octave-devel) is now >> broken during build, because the linked libstdc++ does not contain >> certain symbols. I cannot fix this issue since it requires the correct >> libstdc++ for the given GCC. I would -highly- advise reverting this >> change for the time being. - MLD > > I haven't run into that, but what I'm seeing is that my octave that was > linked against gcc45's libstdc++ now fails at runtime: > > octave(24531) malloc: *** error for object 0x7fff76cc2860: pointer being > freed was not allocated > *** set a breakpoint in malloc_error_break to debug > zsh: abort (core dumped) octave > > I assume this is because gcc45 is (regrettably) built with > --enable-fully-dynamic-string, which makes its libstdc++ > binary-incompatible with the system's, at least for C++ programs that > use the standard string class.
It's not using the system libstdc++, but 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... _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
