Look at the preprocessed output. Grab the compile line from your make
output and add -E to the line if you're using gcc. This puts the
preprocessed output into the named file, which includes the places
from which it gets the includes.
I am not too familiar with the newlib build process, so once you find
where unistd.h is coming from, perhaps someone else will be able to
help with why.
Craig
-----Original Message-----
From: Jason E Miller [mailto:jasonm@MIT.EDU]
Sent: Monday, November 24, 2008 2:41 PM
To: Howland Craig D (Craig)
Cc: newlib@sources.redhat.com
Subject: RE: Compatibility with Debian 4.0?
Craig,
I agree that it seems to be getting unistd.h from elsewhere
but I'm not sure how to determine which one it's pulling in. I'm
guessing that it's getting the one in /usr/include/sys/unistd.h.
I checked and none of the unistd.h files in /usr/include define
the missing values. I'm not trying to build a full toolchain.
I'm just trying to build a native newlib using the installed gcc.
Maybe that's why it's getting the wrong version?
I guess the other strong possibility is that it's getting
the version in newlib/libc/sys/linux/sys/ instead of the one you
patched in newlib/libc/include/sys/. The one in sys/linux/sys
seems to include some system header files (bits/environments.h
and bits/confname.h). Again, /usr/include/bits/confname.h on my
machine does not contain defines for the missing symbols.
Let me know if there's any other information I can provide
that might help shed light on this.
-Jason