Ticket #22234 (closed defect: fixed)
gcc44 should use --enable-fully-dynamic-string
| Reported by: | jwiegley@… | Owned by: | mww@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.8.1 |
| Keywords: | Cc: | dports@… | |
| Port: | gcc44 |
Description
Because Snow Leopard has been built with _GLIBCXX_FULLY_DYNAMIC_STRING (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645), the gcc ports for 10.6 must also. Otherwise, you will get fatal errors if you obtain an empty string from the standard library and then pass it to any library or executable built with your MacPorts gcc. This code, using the "boost" port, demonstrates the problem:
#include <string>
#include <sstream>
#include <boost/variant.hpp>
int main()
{
std::ostringstream buf;
boost::variant<bool, std::string> data;
data = buf.str();
data = false;
return 0;
}
The empty string from ostringstream is different from the empty string as known by Boost, so it will try to deallocate it when the variant changes kind. This is fatal if fully dynamic strings are disabled.
The solution is to add --enable-fully-dynamic-string to the Portfile.
Change History
comment:1 Changed 4 years ago by jmr@…
- Owner changed from macports-tickets@… to mww@…
- Milestone MacPorts 1.8.2 deleted
comment:2 Changed 3 years ago by jwiegley@…
There have been two updates to gc44 since I created this bug. Any reason why it's being ignored? It's an extremely simple change to the Portfile.
comment:3 Changed 3 years ago by mww@…
- Status changed from new to closed
- Resolution set to fixed
fixed; commited in r67282
comment:4 Changed 18 months ago by dports@…
- Cc dports@… added
It looks like this flag is the cause of a number of problems we are having now: at least #27237 and #31171, possibly others.
It doesn't appear to me that Apple's libstdc++ is actually built with fully dynamic strings on Lion, and it sounds like it isn't now on Snow Leopard either (maybe it was previously?)

