This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Enable newlib and libstdc++ for arm-wince-pe [PATCH]


I'll clarify my platform. I'm using a tool-chain for WinCE produced by
Voxware, available here:
http://www.voxware.com/opensource/opensource.html

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
default be?

> 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
not specified?

> 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
library.  ;)

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.
Cheers,
Shaun


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]