[97657] trunk/dports/lang

[Dan Ports]

On Tue, Sep 11, 2012 at 01:37:08PM -0700, Dan Ports wrote:
> 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.

I'm still seeing this with the latest libstdcxx changes.

That's not surprising since gcc45 (and gcc44, but not 46 and later)
was built with --enable-fully-dynamic-string, so it'll try to
deallocate an empty string, which is a static object in the "normal"
libstdc++ built by libstdcxx.

See https://trac.macports.org/ticket/31171 for some history on this, in
particular my comments #35 and #42.

It seems clear now that enabling fully dynamic strings was a mistake,
but I didn't fix it for gcc4[45] before because that would break
compatibility with existing C++ binaries.

It looks like with this change any C++ code built with gcc44 or gcc45
that uses strings needs to be rebuilt -- both ports and anything
user-compiled. It might be worth biting the bullet and doing that to
get all of the long-standing libstdc++ incompatiblities out of the way,
but it's still a pain.

(Maybe this would also be a good time to consider changing the default
variant for most ports from gcc45 to gcc47...)

Dan

-- 
Dan R. K. Ports                UW CSE                http://drkp.net/