This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Newlib Linux Port
- From: Matt Kern <matt dot kern at undue dot org>
- To: newlib at sources dot redhat dot com
- Date: Fri, 25 Nov 2005 13:59:44 +0000
- Subject: Newlib Linux Port
Hello, all.
I am currently working on a project to port linux to a new system-on-chip.
We are at the point where we have the port up and running and are now
refocussing on the user-space side of things. We have a newlib build that
works with libgloss on the bare metal, but we would like to make newlib our
native linux C library.
I've taken a couple of days to look over the newlib source and made a first
stab at a port by creating a minimal setup, and iteratively cross-compiling
it and fixing up the errors. I've run into a few problems that I would like
clarification on:
1) The existing i386 port seems to include files from /usr/include when I
build a native i686 library on my desktop machine. I can understand this
only if newlib is not the main system libc. If it is to be the main
libc, newlib should depend on only the compiler and the linux kernel
headers? If I am right, we should be providing
/usr/include/{,bits/,sys/,foo/}bar.h as part of newlib, no?
I side-stepped this issue for the time being by adding /usr/include to
the system path for our port, in order to satisfy the include directives.
I am well aware of the problems this introduces, but it proved helpful in
seeing how much further we could push on.
2) There appears to be arch dep code in supposedly arch indep parts of the
tree; e.g. newlib/libc/sys/linux/dl/atomicity.h contains ix86 assembly.
I presume these files need to be refactored into arch dep and arch indep
files. However, it isn't clear to me how this should best be achieved.
One option would be to follow the linuxthreads route and add a
.../dl/machine/ subdirectory, complete with arch dep files. This has the
advantage of keeping dl as a self-contained unit, which can be
included/excluded from the build without introducing cruft into the main
tree. The alternative would be to merge the contents of those files
(.../atomicity.h in particular because its contents are not dl specific)
into either the newlib/libc/machine/ or newlib/libcs/sys/linux/machine/
hierarchies.
I'd be grateful for your comments.
Regards,
Matt
--
Matt Kern
http://www.undue.org/