-nostdlibstops this from happening, but if you omit this flag, or link to a dynamic library explicitly, you will end up with imports in your resulting executable. To check if this is the case, use the
PEDUMPutility on the EXE that is generated by the compile process (note that you need to do this against the EXE, not the XBE). An example of a broken EXE is shown below:
Imports Table: KERNEL32.dll OrigFirstThunk: 0000F0C4 (Unbound IAT) TimeDateStamp: 00000000 -> Thu Jan 01 11:00:00 1970 ForwarderChain: 00000000 First thunk RVA: 0000F128 Ordn Name 1 AddAtomA 175 FindAtomA 220 GetAtomNameA xboxkrnl.exe OrigFirstThunk: 0000F0D8 (Unbound IAT) TimeDateStamp: 00000000 -> Thu Jan 01 11:00:00 1970 ForwarderChain: 00000000 First thunk RVA: 0000F13C Ordn Name 49 156 184
Notice how there are imports from the
KERNEL32.dll? This is bad. The
only entry you should see is the one from
xboxkrnl.exe. In addition,
the entries in
xboxkrnl.exe all have to be imported via ordinal, not by name.
If you see a name, then that is bad also (you have most likely used a function that
hasn't yet been defined in the xboxkrnl. See extending the OpenXDK
for more details
<xboxkrnl/xboxkrnl.h>file in your code (if you are calling kernel functions such as
MmAllocateVirtualMemory(). If you do not include the header, the compiler assumes default linkage, which is not correct. Easily fixed by adding the include statement at the top of your file.
freopen ("c:/stdout.txt", "w", stdout); freopen ("c:/stderr.txt", "w", stderr);
winbase.hin August 2004 that caused the OpenXDK build process to fail. They have subsequently been backed out (or more correctly, modified), but not before they made it into production Cygwin builds. Version 0.06 of OpenXDK has a fix to handle all cases of the following error:
/usr/local/openxdk/i386-pc-xbox/lib/libc.a(mallocr.o)(.text+0x1b): In function makeGmListElement': /usr/local/OpenXDK/src/newlib-1.12.0/i386-pc-xbox/newlib/libc/stdlib/../../../../newlib/libc/stdlib/mallocr.c:1112: undefined reference to `__imp__LocalAlloc@8'