This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/11170] bug in ctype_inline.h header file (undefined __istype will break compilation)
- From: "rittle at latour dot rsch dot comm dot mot dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 12 Jun 2003 22:18:00 -0000
- Subject: [Bug libstdc++/11170] bug in ctype_inline.h header file (undefined __istype will break compilation)
- References: <20030612095704.11170.ronald@landheer.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11170
------- Additional Comments From rittle@latour.rsch.comm.mot.com 2003-06-12 22:17 -------
Subject: Re: New: bug in ctype_inline.h header file (undefined __istype will break compilation)
In article <20030612095704.11170.ronald@landheer.com> you write:
> $ ../src/configure [...] --target=i386-unknown-freebsd4.7 --with-newlib [...]
> [...] Make produced a number of errors due to missing header files [...]
This is not a supported configuration at the moment (this is true for
many "UNIX" cross-targets within libstdc++-v3 AFAIK). I have no
opinion on whether the above should or should not be supported but we
will review any patches posted to the libstdc++ list to improve that
situation. For one thing, AFAIK, the libstdc++-v3 configuration
method looks at target triple without regard to presence of
--with-newlib to decide which configuration files to select. Those
selected files clearly use knowledge of the target OS and expect
system headers to be present not newlib headers.
I.e. if there is a bug, then I suggest it is not in:
libstdc++-v3/config/os/bsd/freebsd/ctype_inline.h
rather it is in the selection process in:
libstdc++-v3/configure* (which should be selecting
libstdc++-v3/config/os/newlib/ctype_inline.h et al. in the presence
of --with-newlib).
Ah, BTW, you thought it was an error to use __istype before checking
it to guard the use of another entity called __maskrune. That is
not-a-bug (you will have to study the *full* history of
/usr/include/ctype.h on freebsd to understand why).
Regards,
Loren (with both libstdc++-v3 and freebsd maintainer hat on)