[97657] trunk/dports/lang

[Jeremy Huddleston Sequoia]

On Sep 11, 2012, at 13:37, Dan Ports <dports at macports.org> 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...