Re: Libstdc++ problems
Re: Libstdc++ problems
- Subject: Re: Libstdc++ problems
- From: Steve Caine <email@hidden>
- Date: Wed, 28 Feb 2007 12:22:10 -0500
Tom, Mike,
I had a similar problem with std::string while porting a plug-in
project from CodeWarrior to Xcode; calls to string::assign() were
producing garbage.
In my case, removing the flag "-flat_namespace" from the build
setting 'Other Linker Flags' was enough to get it working again.
Tom's hint about two-level namespaces was what led me to try this.
And yes, this is a plug-in for (Quark)XPress, a/k/a an 'XTension'. So
far, I can't find any new problems introduced by removing this
setting (which is present in all the sample Xcode projects provided
by the manufacturer of the host application for this plug-in).
This version of the host is built with CodeWarrior, while my (ported)
plug-in is built with Xcode, hence the conflict between different
implementations of std::string. Later versions of the host are
compiled with Xcode, so this problem should go away regardless of
namespace setting, as both plug-in and host will have been built with
Xcode.
Steve Caine
On Tue, 27 Feb 2007 01:03:05 +0100, Thomas Engelmeier wrote:
Am 26.02.2007 um 22:00 schrieb Mike Linden:
Below is the debugger showing were it went for the exception.
My guess is whatever is causing the problem with c_str() is also
causing this problem.
catch the exception (by reference), print theException.what();
Is it possible the some type of casting is needed, that is
different from
normal C++ standards?
If in C++ you need casting, usually you have messed something up.
Either from the design point of view or the implemenattion POV.
#0 0x9004802c in kill
#1 0x9012dfb4 in abort
#2 0x0024b63c in std::dthandler
#3 0x0024b5d0 in std::terminate
#4 0x00248654 in ExPPC_ThrowHandler
#5 0x00248078 in __throw_vec
#6 0x00248408 in __throw
#7 0x00280af0 in std::string::replace
#8 0x0028b104 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string
#9 0x0028a548 in std::string::substr
#10 0x0105cd84 in XPDBSearch::_parseReadBufferAdv at
XPDBSearch.cpp:2533
The XP in XPDBSearch does not happen to stand for XPress, does it?
The OS X incarnation of the dyld linker will use the first loaded
version of an symbol for ALL later loaded libraries of the same host.
In case an plug-in host was buildt with another implemenation of
std::string::replace, e.g. because it was buildt with CodeWarrior,
the plug-in might resolve the some but not all symbols to the
incompatible version.
Two-level namespaces might or might not help.
HTH,
Tom_E
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden