This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/6827: Unreasonable dependencies on ctype.h
- From: Tony Bryant <brd at paradise dot net dot nz>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 29 May 2002 00:42:23 +1200
- Subject: Re: libstdc++/6827: Unreasonable dependencies on ctype.h
- Organization: Bryant Research & Development
- References: <20020527115347.2549.qmail@sources.redhat.com>
> Synopsis: Unreasonable dependencies on ctype.h
>
<snip>
> State-Changed-Why:
> I think you are mistaken. The ctype implementation is pretty flexible,
> although a bit baroque.
>
> See config/os/newlib/bits/ctype* for the default cross compiler bits
> (using newlib.) There is another configuration for glibc (under
> gnu-linux/bits/ctype*). There are also specific configs for most other
> commercial unices. You might check it out.
Firstly, please accept my apologies for presenting this bug report without
doing enough background research.
Now, I think I've got to the bottom of it, and it appears what is happening
is configure is setup to pick the newlib "os" interface for most embedded
cross targets,whereas I'd imagined it would be using the generic "os"
interface.
If anyone else who is in the same boat as me, the line to change is:
os_include_dir="config/os/newlib"
in libstdc++-v3/configure.in ; change it to
os_include_dir="config/os/generic"
and libstdc++ will be built only using the isXXXXX & toXXXXX of the installed
target ctype.h.
Or just use newlib.
How valid is the assumption that we'll be using always be using newlib on
cross compilers?
Is is reasonable for configure to check if newlib is installed, and if
not, resort to the generic interface?