Re: Darwin vs. libstdc++

[Stan Shebs <shebs at apple dot com>]

Bryce McKinlay wrote:
> 
> I've been trying to build GCC on darwin, at least to get it as far as
> the libjava build. It seems that there are issues with libstdc++.

Yes, that's been my private hell for the past couple weeks.

> First, why does t-darwin want to multilib? I dont know if this causes
> any actual problems, but it does suck waiting for multilibs to build.

What a coincidence - I sent that around as an issue within Apple
just yesterday.  The Darwin kernel is built with -msoft-float, but
it uses a special libgcc, and I'm not yet clear on how that libgcc
is built, because it doesn't use multilib mechanism.  In any case,
I believe we will want to do this change.

> Next, theres big problems when we hit libstdc++ proper, starting with
> basic_file.cc:
> 
> [...]
> /Users/bryce/cvs/gcc/build/powerpc-apple-
> darwin1.4/libstdc++-v3/include/bits/std_cctype.h:57: `isalnum' not
> declared
> [...]

This is a known boner in Darwin headers, and it's been reported to
the people in charge, but I don't think they did anything about it
for 10.1.  It needs a fixincludes addition.

> With this patch in place, everything builds okay, but I get this linker
> warning:
> 
> ranlib: same symbol defined in more than one member in:
> .libs/libstdc++.a (table of contents will not be sorted)
> ranlib: file: .libs/libstdc++.a(time.o) defines symbol:
> __ZNKSt11__timepunctIcE13_M_put_helperEPcmPKcPK2tm
> ranlib: file: .libs/libstdc++.a(locale-inst.o) defines symbol:
> __ZNKSt11__timepunctIcE13_M_put_helperEPcmPKcPK2tm

I haven't noticed these myself, mostly because there is another
serious problem, namely that exception handling doesn't work.
Apple independently (sigh) implemented dwarf2-based exception
handling in 2.95.2, thus the expectation is that we use that
rather than sjlj, so I've been plodding through the maze of
twisty dwarf2 EH bits trying to get them to work on Darwin.

Stan