This is the mail archive of the
mailing list for the GCC project.
Re: Enable newlib and libstdc++ for arm-wince-pe [PATCH]
- From: Shaun Jackman <sjackman at pathwayconnect dot com>
- To: Jim Wilson <wilson at tuliptree dot org>
- Cc: gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: 15 Jul 2003 08:29:23 -0600
- Subject: Re: Enable newlib and libstdc++ for arm-wince-pe [PATCH]
- Organization: Pathway Connectivity
- References: <email@example.com> <3F13922C.firstname.lastname@example.org>
I'll clarify my platform. I'm using a tool-chain for WinCE produced by
Voxware, available here:
This is primarily a binary distribution, though source is available. The
tool-chain is based on binutils 2.11.2, gcc 3.2, newlib 1.11.0. It's
taken me some time, but I can now compile the tool-chain from source
using recent versions (binutils 2.14, gcc 3.3), having forward ported
Voxware's patches. I'm trying to move these patches upstream now.
The basic architecture of the tool-chain uses newlib wherever possible
to provide libc functions. The libc (coredll) of Pocket PC (Windows CE)
has some non-standard implementations of libc functions, particularly
with respect to sockets. Some of Voxware's newlib functions wrap calls
(convert parameters etc) and call the equivalent coredll function. I
haven't yet tried to push these wrapping functions upstream, as the
newlib implementation is quite non-standard and doesn't fit into newlib
all that well. Although, given time, I'd love to try to fix this.
I'm not sure how else a working tool-chain for Pocket PC is produced. I
scoured the web, and this is all I could find. If it's possible to build
a tool-chain using only coredll (no newlib), that's news to me.
On Mon, 2003-07-14 at 23:33, Jim Wilson wrote:
> WinCE is a target RTOS that has its own C library, in which case you
> should not be using newlib by default. Using newlib means some OS
> features aren't going to work correctly or won't be available.
That's a good point. If --with-sysroot is specified to provide coredll,
then the tool-chain should use the native libc (coredll). Otherwise, if
--with-newlib is specified, then newlib should be used. What should the
> The libstdc++ comment says that it won't build on top of the WinCE C
> library. You haven't tried that apparently, so we still need
> $(libstdcxx_version) added to noconfigdirs in the default case.
Can $(libstdcxx_version) be added to noconfigdirs if --with-newlib is
> Is there a reason why you are trying to use newlib instead of the
> standard C library for the target?
The libstdc++ comment says that it won't build on top of the WinCE C
Also, I'm building cross-platform (arm-wince-pe and i686-pc-gnu-linux)
code and need a standard libc, which coredll is not.
> I see that --with-headers/--with-libs cause with_newlib=no as a
> side-effect, so I think we can check the value of that when deciding
> whether to add libstdcxx_version to noconfigdirs. That way we can
> continue to do it for the normal case, and yet allow you to build it
> when using newlib. I suggest you write a patch that does that.
Ah, that answers my question above. Good. I like that solution. I'm new
to the internals of the gcc configure process, but this should be a nice
introductory project for me.
> This also means that it is OK to remove target-newlib from noconfigdirs,
> because it will be in skipdirs in the normal case, so there is no need
> to also have it in noconfigdirs.
How do skipdirs and noconfigdirs differ? Where can I find documentation
on the internals of the gcc configure process?
> The second part of your patch is already fixed on mainline.
> I see that --with-sysroot does not set with_newlib=no like the
> with-headers/with-libs options do. I suspect that is a bug, but not one
> that you have to worry about.
Thanks for your informative response.