[97657] trunk/dports/lang

[Michael Dickens]

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 <dports at macports.org> 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...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120913/a89dce39/attachment.html>