Hi, The following program fails on Mac OS X with both 4.7 and 4.8. $ uname -a Darwin erebus.lrde.epita.fr 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 $ g++-mp-4.7 --version g++-mp-4.7 (MacPorts gcc47 4.7.1_1) 4.7.1 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-mp-4.8 --version g++-mp-4.8 (MacPorts gcc48 4.8-20120701_0) 4.8.0 20120701 (experimental) Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat simpleaut.cc # define _GLIBCXX_DEBUG 1 # include <sstream> int main() { std::ostringstream s; s.str(); } $ g++-mp-4.8 tests/unit/simpleaut.cc $ ./a.out a.out(28056) malloc: *** error for object 0x10a5f2340: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug zsh: abort ./a.out (gdb) bt #0 0x00007fff89bf582a in __kill () #1 0x00007fff89833a9c in abort () #2 0x00007fff8989284c in free () #3 0x0000000100000b86 in __gnu_cxx::new_allocator<char>::deallocate (this=0x7fff5fbff847, __p=0x1000d0340 "") at ext/new_allocator.h:102 #4 0x0000000100000b58 in std::string::_Rep::_M_destroy (this=0x1000d0340, __a=@0x7fff5fbff89f) at bits/basic_string.tcc:451 #5 0x0000000100000ae6 in std::string::_Rep::_M_dispose (this=0x1000d0340, __a=@0x7fff5fbff89f) at bits/basic_string.h:251 #6 0x00000001000009fd in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string (this=0x7fff5fbffa20) at bits/basic_string.h:541 #7 0x0000000100000968 in main () at tests/unit/simpleaut.cc:7
This is not a GCC bug, please report it to MacPorts not here. At a guess I'd say you're linking to the system libstdc++.so not the one from your mp builds, and the mp builds do not use the same setting for --enable-fully-dynamic-string as the system libs.
Not a GCC bug as Mac OS X's installed libstdc++ is built with --enable-fully-dynamic-string while the mac ports one is not.
Andrew, I'm not actually sure about that, see https://trac.macports.org/ticket/22234 But in any case, it's a problem with MacPorts' GCC package not FSF's GCC.
Hi People, I have therefore reported this to MacPorts, see http://trac.macports.org/ticket/35070 . The outcome is that (i) with --enable-fully-dynamic-string fails to build on MacPorts, and (ii), no, the linking is properly done with the MacPorts' version of stdlibc++: > also when trying your example the resuling binary is linked to _our_ gcc's C++-lib So really, there seem to be something weird about this on OS X, as indeed is shown in other tickets. What course of action would you recommend?
(In reply to comment #4) > What course of action would you recommend? I don't understand what the comments in the macports trac mean, but as far as I'm concerned there's nothing for us to do, it's an issue with the macports build, not GCC. If they want to report a different bug about --enable-fully-dynamic-string that's a separate issue and will be dealt with if it's reported properly.
Not a GCC bug? Really? I beg to differ. - Bug 54173 - Bug 33021 - Bug 64504
One of those bugs is apparently not present in 4.2 or later, are you sure it's the same? Do you have a reproducible testcase to show the bug, not just "use macports, it breaks"? or only links to other reports that show up for related search terms?
i.e. do you have the exact commands to build a gcc that shows the problem? So it can be reproduced from a clean source tarball, without external dependencies.