Back to basics

["Craig Edwards" <craig at haenterprises dot com dot au>]

I've spent the last week or so trying to create my own port of newlib and,  
despite having learnt an awful lot, I am still not sure I understand fully  
the way newlib wants to work.  I was hoping to get some basic advice to  
ensure I am heading down the right track.

When it all comes down to it, I want to produce libc.a/libm.a files that  
contain object code that I can link into a normal Windows PE-executable.   
I need these .a files to be completely standalone with no dependencies on  
any external DLL (cygwin, win32, or otherwise).  I have no preference as  
to whether my replacement newlib system calls (open, read, et al) are  
already contained within the libc.a or whether I need to link them in  
separately.

In essence, I need to create a normal PE .exe, but instead of using the  
normal libc library, I want to use newlib (and thus, use my specific  
system calls).  Does that make sense?  Any advice I can get on the best  
way to achieve this would be much appreciated.  Thanks a lot.

--
Craig Edwards

To provide some context, my approach thus far has been to create a target  
called i386-pc-xbox with the following settings:

  xbox)
  machine_dir=i386
  ;;

  i[34567]86-*-xbox)
  sys_dir=xbox
  newlib_cflags="${newlib_cflags} -D_COMPILING_NEWLIB"
  ;;

And then configuring it using:

  ../newlib-1.12.0/configure --target=i386-pc-xbox --with-newlib  
--without-headers

This makes the libc.a and libm.a, but when I try to link using:

  gcc blah.c -nostdlib -L. -lc -lnosys -lgcc

I get a bunch of errors saying it can't find ___main, __fstat64_r and  
_setmode.  If I look at the code for this, I see it is wrapped with  
__USE_INTERNAL_STAT64 and __SCLE #ifdefs (very cygwin specific), and I am  
not sure how to get handle this.  I was thinking that maybe I am better  
off subverting the i686-pc-cygwin target somehow, rather than creating my  
own target.