Darwin vs. libstdc++

Darwin vs. libstdc++

[Bryce McKinlay]

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++.

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.

Index: t-darwin
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/rs6000/t-darwin,v
retrieving revision 1.4
diff -u -r1.4 t-darwin
--- t-darwin    2001/06/28 19:55:53     1.4
+++ t-darwin    2001/10/09 06:14:25
@@ -21,10 +21,10 @@
             $(TM_P_H)
         $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<

-# Build the libraries for both hard and soft floating point
+# Don't build the libraries for both hard and soft floating point

-MULTILIB_OPTIONS = msoft-float
-MULTILIB_DIRNAMES = soft-float
+MULTILIB_OPTIONS =
+MULTILIB_DIRNAMES =

  LIBGCC = stmp-multilib
  INSTALL_LIBGCC = install-multilib


Next, theres big problems when we hit libstdc++ proper, starting with 
basic_file.cc:

/Users/bryce/cvs/gcc/build/gcc/xgcc -B/Users/bryce/cvs/gcc/build/gcc/ 
-nostdinc++ -L/Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/src 
-L/Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/src/.libs 
-B/Users/bryce/devo/gcc/powerpc-apple-darwin1.4/bin/ 
-B/Users/bryce/devo/gcc/powerpc-apple-darwin1.4/lib/ -isystem 
/Users/bryce/devo/gcc/powerpc-apple-darwin1.4/include -nostdinc++ 
-I/Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/include/powerpc-apple-darwin1.4 
-I/Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/include -I../../../../libstdc++-v3/libsupc++ 
-I../../../../libstdc++-v3/libmath -g -O2 -fno-implicit-templates -Wall 
-Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once 
-g -c basic_file.cc -o basic_file.o
In file included from /Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/include/bits/localefwd.h:43,
                  from /Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/include/bits/std_ios.h:43,
                  from /Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/include/bits/basic_file.h:40,
                  from basic_file.cc:34:
/Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/include/bits/std_cctype.h:57: `isalnum' not 
declared
/Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/include/bits/std_cctype.h:58: `isalpha' not 
declared
/Users/bryce/cvs/gcc/build/powerpc-apple-
darwin1.4/libstdc++-v3/include/bits/std_cctype.h:59: `iscntrl' not 
declared
[ blah blah blah ]

It seems that libstdc++ expects these ctype declarations to be real 
functions, but darwin's /usr/include/ctype.h only defines them as 
macros! Apparently every other platform that libstdc++ must declare 
these as functions, so this is a bug with darwin? I was able to work 
around it by patching darwin's header as below.

Re: Darwin vs. libstdc++

[Stan Shebs]

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

Re: Darwin vs. libstdc++

[Bryce McKinlay]

Stan Shebs wrote:

>>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.
>>
>In any case, I believe we will want to do this change.
>

I agree.

>>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.
>

This *could* be addressed in fixincludes, but it would be very ugly and 
have the potential to break when the header actually does get fixed. I 
couldn't see a reasonable way to do it without the chance of breaking 
future, fixed headers (but hey I don't really know fixincludes).

In any case, something should be done about it one way or the other, asap!

regards

Bryce.

Re: Darwin vs. libstdc++

[Phil Edwards]

On Tue, Oct 09, 2001 at 07:50:47PM +1300, Bryce McKinlay wrote:
> /Users/bryce/cvs/gcc/build/powerpc-apple-
> darwin1.4/libstdc++-v3/include/bits/std_cctype.h:59: `iscntrl' not 
> declared
> [ blah blah blah ]
> 
> It seems that libstdc++ expects these ctype declarations to be real 
> functions, but darwin's /usr/include/ctype.h only defines them as 
> macros! Apparently every other platform that libstdc++ must declare 
> these as functions, so this is a bug with darwin?

Certain entities in the standard C library are allowed to be either a
macro or a function; in the standard C++ library they are required to be
a function.  (Since macros don't obey scope and thus have a tendency to
appear where they oughtn't.)

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Darwin vs. libstdc++

[Stan Shebs]

Phil Edwards wrote:
> 
> On Tue, Oct 09, 2001 at 07:50:47PM +1300, Bryce McKinlay wrote:
> > /Users/bryce/cvs/gcc/build/powerpc-apple-
> > darwin1.4/libstdc++-v3/include/bits/std_cctype.h:59: `iscntrl' not
> > declared
> > [ blah blah blah ]
> >
> > It seems that libstdc++ expects these ctype declarations to be real
> > functions, but darwin's /usr/include/ctype.h only defines them as
> > macros! Apparently every other platform that libstdc++ must declare
> > these as functions, so this is a bug with darwin?
> 
> Certain entities in the standard C library are allowed to be either a
> macro or a function; [...]

Really?  I don't see anything in my C89 or C99 specs that suggests
that isalnum and friends don't need function definitions.  For one
thing, you can't take the address of a macro, so the standard would
have to say explicitly that the address of isalnum is undefined.

Stan

Re: Darwin vs. libstdc++

[Neil Booth]

Stan Shebs wrote:-

> Really?  I don't see anything in my C89 or C99 specs that suggests
> that isalnum and friends don't need function definitions.  For one
> thing, you can't take the address of a macro, so the standard would
> have to say explicitly that the address of isalnum is undefined.

You could have both.  Anything with a following '(' uses the macro.
Taking the address of the function will not have a following '(', and
so would not be treated by CPP as a macro invocation.

Neil.

Re: Darwin vs. libstdc++

[Stan Shebs]

Neil Booth wrote:
> 
> Stan Shebs wrote:-
> 
> > Really?  I don't see anything in my C89 or C99 specs that suggests
> > that isalnum and friends don't need function definitions.  For one
> > thing, you can't take the address of a macro, so the standard would
> > have to say explicitly that the address of isalnum is undefined.
> 
> You could have both.  Anything with a following '(' uses the macro.
> Taking the address of the function will not have a following '(', and
> so would not be treated by CPP as a macro invocation.

Exactly, which is why I suspect that people think the standard
doesn't require that functions be available.  One of those reasons
to have testsuite, so that well-meaning people don't remove the
required bits and leave only the optimization in the headers.
(Ironically, this is correct in every other flavor of BSD that I
looked at - only NeXT/Apple managed to get this wrong, haven't
studied the version trail to find an actual miscreant though.)

Stan

Re: Darwin vs. libstdc++

[Dale Johannesen]

On Tuesday, October 9, 2001, at 11:17 AM, Neil Booth wrote:

> Stan Shebs wrote:-
>
>> Really?  I don't see anything in my C89 or C99 specs that suggests
>> that isalnum and friends don't need function definitions.  For one
>> thing, you can't take the address of a macro, so the standard would
>> have to say explicitly that the address of isalnum is undefined.
>
> You could have both.  Anything with a following '(' uses the macro.
> Taking the address of the function will not have a following '(', and
> so would not be treated by CPP as a macro invocation.

Yes.  A function is required to exist (explicitly, in c89,
I don't have the other specs handy); an additional macro implementation
is permissible, but not required.  The functions are there in the Darwin
library; it is a known bug in <ctype.h> that some declarations are missing.
Here is a complete list:  isalnum, isalpha, iscntrl, isdigit, isgraph,
islower, isprint, ispunct, isspace, isupper, isxdigit.  Anyone so
inclined can hack around the problem by adding declarations for these to
<ctype.h> (before the existing macro definitions).  Sorry, none of the
Apple people who post to this list has any control over when (or whether)
this gets fixed in releases.

Re: Darwin vs. libstdc++

[Geoff Keating]

Dale Johannesen <dalej@apple.com> writes:

> The functions are there in the Darwin library; it is a known bug in
> <ctype.h> that some declarations are missing.  Here is a complete
> list: isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint,
> ispunct, isspace, isupper, isxdigit.  Anyone so inclined can hack
> around the problem by adding declarations for these to <ctype.h>
> (before the existing macro definitions).  Sorry, none of the Apple
> people who post to this list has any control over when (or whether)
> this gets fixed in releases.

There's always fixincludes...

-- 
- Geoffrey Keating <geoffk@geoffk.org>