Problem with debug Boost, Mac OS X and g++ 4.6
I'm not sure yet whether this is a Boost issue, or a g++ 4.6 issue. I've compiled Boost 1.46.1 on Mac OS X using g++ 4.6 and these build options: sh bootstrap.sh && ./bjam debug \ --toolset=darwin --build-type=complete --layout=versioned \ define=_GLIBCXX_FULLY_DYNAMIC_STRING=1 define=_GLIBCXX_DEBUG=1 \ install Then I build and execute the following example code: #include <boost/regex.hpp> #include <string> int main(int argc, char *argv[]) { boost::regex expr("foo.*bar"); return boost::regex_search(std::string(argv[1]), expr) ? 0 : 1; } with this compile/link command: g++-mp-4.6 -D_GLIBCXX_FULLY_DYNAMIC_STRING=1 -D_GLIBCXX_DEBUG=1 \ -g -o regex regex.cc -lboost_regex-xgcc46-d-1_46_1 and the result is: terminate called after throwing an instance of 'std::bad_cast' what(): std::bad_cast This is happening in boost::re_detail::cpp_regex_traits_base<char>::imbue, on line cpp_regex_traits.hpp:218. The same everything, using g++ 4.5, works fine, so maybe this is a g++ 4.6 bug? I seem to recall having seen this problem before, due to mismatching a debug Boost with a non-debug client app, or something similar. But I've have verified that my client app is using the same flags that I build Boost with. Has anyone run into this? Do I need to take this bug to the g++ folks? Any pointers, ideas? Thanks, John
At Wed, 30 Mar 2011 18:48:09 -0400, John Wiegley wrote:
I'm not sure yet whether this is a Boost issue, or a g++ 4.6 issue. I've compiled Boost 1.46.1 on Mac OS X using g++ 4.6 and these build options:
sh bootstrap.sh && ./bjam debug \ --toolset=darwin --build-type=complete --layout=versioned \ define=_GLIBCXX_FULLY_DYNAMIC_STRING=1 define=_GLIBCXX_DEBUG=1 \ install
Maybe this will help: First, "toolset=" takes no leading dashes. Second, I believe your g++ 4.6 is a plain GCC (toolset=gcc) and not an Apple build (toolset=darwin). -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams <dave@boostpro.com> writes:
First, "toolset=" takes no leading dashes.
Second, I believe your g++ 4.6 is a plain GCC (toolset=gcc) and not an Apple build (toolset=darwin).
I've edited darwin.jam to use g++-mp-4.6, since toolset=gcc didn't work for me the last time I tried it. I'll give it another try though. Wonder why it works fine for 4.5 though? John
On Mar 30, 2011, at 9:35 PM, Dave Abrahams wrote:
Second, I believe your g++ 4.6 is a plain GCC (toolset=gcc) and not an Apple build (toolset=darwin).
Ah, bjam doesn't accept toolset=gcc on Mac OS X. It just selects darwin anyway. How do others build with a different compiler on OS X? John
On 30 Mar 2011, at 23:48, John Wiegley wrote:
I'm not sure yet whether this is a Boost issue, or a g++ 4.6 issue. I've compiled Boost 1.46.1 on Mac OS X using g++ 4.6 and these build options:
sh bootstrap.sh && ./bjam debug \ --toolset=darwin --build-type=complete --layout=versioned \ define=_GLIBCXX_FULLY_DYNAMIC_STRING=1 define=_GLIBCXX_DEBUG=1 \ install
Did you build g++ with _GLIBCXX_FULLY_DYNAMIC_STRING? Or are you sure where it is picking up it's standard library from? My suspicion is that you are hitting the (which you seem to know about) _GLIBCXX_DEBUG and std::string bug in Mac OS X. Unfortunately I don't have a good answer on how to avoid it, I have tried various workarounds, but I always seem to end up getting bitten in the end.
Then I build and execute the following example code:
#include <boost/regex.hpp> #include <string>
int main(int argc, char *argv[]) { boost::regex expr("foo.*bar"); return boost::regex_search(std::string(argv[1]), expr) ? 0 : 1; }
with this compile/link command:
g++-mp-4.6 -D_GLIBCXX_FULLY_DYNAMIC_STRING=1 -D_GLIBCXX_DEBUG=1 \ -g -o regex regex.cc -lboost_regex-xgcc46-d-1_46_1
and the result is:
terminate called after throwing an instance of 'std::bad_cast' what(): std::bad_cast
This is happening in boost::re_detail::cpp_regex_traits_base<char>::imbue, on line cpp_regex_traits.hpp:218.
The same everything, using g++ 4.5, works fine, so maybe this is a g++ 4.6 bug? I seem to recall having seen this problem before, due to mismatching a debug Boost with a non-debug client app, or something similar. But I've have verified that my client app is using the same flags that I build Boost with.
Has anyone run into this? Do I need to take this bug to the g++ folks? Any pointers, ideas?
Thanks, John _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Christopher Jefferson <chris@bubblescope.net> writes:
Did you build g++ with _GLIBCXX_FULLY_DYNAMIC_STRING? Or are you sure where it is picking up it's standard library from?
My suspicion is that you are hitting the (which you seem to know about) _GLIBCXX_DEBUG and std::string bug in Mac OS X. Unfortunately I don't have a good answer on how to avoid it, I have tried various workarounds, but I always seem to end up getting bitten in the end.
Yes, I'm quite sure fully-dynamic-string is used everywhere. I have some history with that particular issue, and its symptoms are not this. I've narrowed down the problem to the following, in use_facet: 31 = std::collate<char>::id._M_id() 28 = std::locale()._M_impl->_M_facets_size 31 is an index into the facets array. 28 is the size of that array, as seen through std::locale(). It would seem that the array std::collate<char> got added to, and the array referenced by std::locale(), are not the same. I've confirmed that both my executable, and the boost_regex dylib, both reference the same libstdc++. I'll need to build g++ with debugging to trace this any further into the locale code. John
participants (4)
-
Christopher Jefferson -
Dave Abrahams -
John Wiegley -
Michel MORIN