This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]