* On 31.10.2011 12:26 AM, Jonathan Wakely wrote:
> On 30 October 2011 22:38, Mihai Moldovan wrote:
>>> If ld can't be linked with your new libstdc++ then it is probably due
>>> to an ABI compatibility. My guess would be something to do with
>>> fully-dynamic-string but you claim that's being used correctly. How
>>> was the system libstdc++ configured?  How are you configuring your gcc
>>> builds?
>> I suspect that too, but the build system should really not force the
>> libstdc++ on ld, or things like that may happen.
>> If I interpret www.ionic.de/libstdc++3.diff correctly (diff between GCC
>> 4.5.3 and GCC 4.6.2 libstdc++ with some fuzzyness), the ABI version
>> changed from 6 to 7. Commonly this happens on breaking ABI changes.
> No, the library ABI version has not changed.  The libstdc++ from GCC
> 4.6 is backward compatible with the one from libstdc++ 4.5

Oh, hm, I see... then I may have misinterpreted the namespace version
change, sorry.

> And how was the system compiler (and therefore the system libstdc++) configured?

If I knew... they may or may not have even used clang instead of gcc,
which makes matters worse. (At least they used clang for compiling ld.)

>> I'll try to rebuild with --disable-fully-dynamic-string, but per
>> http://newartisans.com/2009/10/a-c-gotcha-on-snow-leopard/ I assume this
>> feature is used in the libc and thus cause even more problems then it
>> solves.
> You can try it, but I doubt it will work.  If system libraries on Mac
> OS X use fully-dynamic-string (which I believe they still do) then you
> need to use that for your build too.

Wow, something weird just happened. With --disable-fully-dynamic-string,
GCC 4.6.2 build and installed fine... so maybe
_GLIBXX_FULLY_DYNAMIC_STRING is not used in the system libstdc++ after
all. Whilst it's at least compiling now, I'm kind of totally confused.