CeGCC cross compiler for PocketPC

This document describes the structure of the CeGCC/MinGW32ce directory tree and of its modules. By modules we mean the different softwares or their components, which we assemble to create CeGCC and MinGW32ce.

Directory structure - src/

src/mingw

This directory's primary purpose is to hold the necessary startup code and needed static code to be able to use coredll.dll as only runtime. You can consider src/mingw a gcc replacement for corelibc.lib in other development tools. Added to that, there are some other goodies.

src/mingw/mingwex

Mingwex holds the MinGW added extensions to add support for C99 and some POSIX functionality not found in COREDLL. See http://www.mingw.org/MinGWiki/index.php/mingwex Please don't just add stubs there. Those are more harmful than good, because if you do, an app using autoconf's AC_CHECK_FUNC will find it, and instead of providing a proper replacement, will call the stubbed one, which won't work obviously.

src/mingw/profile

src/mingw/mingwex/wince

This is where one places wince code that doesn't fit in the other mingwex dirs, because the desktop versions of mingw don't need it. Keep in mind, that the less we diverge from the upstream versions, the easiest we can pull from updates they have.

src/mingw/include

The headers in mingw/include correspond to the libc part of coredll.dll (stdio.h, stdlib.h, etc, etc.). This contrasts with src/w32api/include which holds headers corresponding to win32 api definitions, there is no libc runtime stuff there. The arm-wince-mingw32ce toolchain uses only the Windows CE DLLs, the arm-wince-cegcc uses newlib, so it uses the corresponding newlib headers. You can't (shouldn't) mix headers from newlib, and from mingw/include.

Take a look, there are headers with the same name, for instance, there is a stdio.h in newlib, and a stdio.h too in mingw/include, but they are incompatible. Usually the headers from newlib are more complete, but so is the c runtime support in newlib. The danger in mixing the two sets is in that some (many/most) constants and structures are completely different in the two.

Take for instance the stdio functions. The FILE struct (think fprintf, fwrite, etc) is totally incompatible in the two. Sure, struct FILE is (mostly) an opaque structure, but there are cases where an inline function accesses its members directly. Take stdout for instance, in newlib, it maps to something like '_impure_ptr->_stdout' (from heart, so the names may be wrong), while in mingw/include (mingw32ce), it maps to '_getstdfilex(1)'.

Now imagine a cegcc app, calling newlib's version of fprintf like so:

fprintf (stdout, "Look ma, I can crash!\n");
which after preprocessing, maps to:
fprintf (_getstdfilex(1), "Look ma, I can crash!\n");
If that doesn't crash, it will be pure luck.

src/w32api/include

This holds headers corresponding to win32 api definitions, there is no std c runtime stuff there.

src/newlib

Newlib is a portable C library implementation. We're using it to augment the arm-wince-cegcc toolset, because in many apps, the libc part of coredll is very limited.

src/newlib/newlib/libc/sys/wince

Our implementation of newlib is itself augmented with some Windows CE specific stuff. Look here for more information regarging this layer. The very minimal unix-like layer provided by CeGCC.

Comparison to other libraries and modules

MSVCRT

This is Microsoft Visual C RunTime library, the runtime library currently most used in Windows NT/9x. MSDN describes msvcrt.dll here as a multi-threaded dynamic link library (aka DLL). In this page it is further described as a system library that is intended for use by Windows itself, but that you're allowed to use in applications.

Current versions of Windows CE use coredll.dll instead.

Information

Support

Powered by Sourceforge.net