Certainly fixing that sort of issue seems wise. Folks trying to build octave-devel with gcc45 continue to have that issue. I'm using gcc47, and octave-devel builds but does not execute because, I think, of improper dyld linking -- a symbol is not where it is expected. See ticket #36103 for more discussion. I truly do not know what the issue is with octave-devel, but, IMHO, everything thus far points to it being something with the latest gcc changes: octave-devel worked just fine before these changes, and no longer does. - MLD
On Sep 13, 2012, at 5:09 PM, Dan Ports <[email protected]> wrote: 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...)
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
