[Barrelfish-users] Newlib libc ported

[Kevin Elphinstone]

http://sourceware.org/newlib/COPYING.NEWLIB

Seems BSD (LGPL for some parts), but the list of copyrights is massive - 36 copyright holders. It almost makes entertaining reading......

	- Kevin

> -----Original Message-----
> From: Timothy Roscoe [mailto:troscoe at inf.ethz.ch]
> Sent: Monday, 19 December 2011 5:44 PM
> To: Zeus Gómez Marmolejo
> Cc: barrelfish-users at lists.inf.ethz.ch
> Subject: Re: [Barrelfish-users] Newlib libc ported
> 
> 
> Dear Zeus,
> 
> This looks really useful - can you tell me what licence Newlib uses?
> 
>  -- Mothy
> 
> At Mon, 19 Dec 2011 17:06:24 +0100, Zeus Gómez Marmolejo
> <zeus.gomez at bsc.es> wrote:
> > Dear Barrelfish developers,
> >
> > I would like to keep updated with our progress here at BSC. We have
> > successfully ported the Redhat Newlib to Barrelfish as a libc replacement.
> > To do so, some code in the posixcompat has been rewritten to not call
> > in turn to the libc. This way, calls to write(), read() or sbrk() have
> > been lightly modified to implement the functionality present in the
> > existing libc. The objective has been to not touch the newlib.
> >
> > Right now, all programs link with newlib, being able to boot all
> > system with this library. Also, in case the old library is needed,
> > I've added a variable in the Config for Hake to be able to select
> > which libc library to compile. Both of them are working. To do so, I
> > had to separate includes that were system dependent and others that
> were libc dependent.
> >
> > This newlib has been included in the Barrelfish tree but can be used
> > also with the independent gcc cross-compiler that we also developed
> > here. This gives full C++ support with the GNU libstdc++ and exception
> support.
> >
> > Some technical details that I had to cope... Now all libraries (vfs,
> > posixcompat, newlib, lwip, nfs...) are always linked in. Because
> > newlib always needs posixcompat as it has the "system calls"
> > implementation. Due to this, vfs, nfs and lwip have to be linked too
> > as the implementation of
> > read() write() have calls to vfs and nfs. In some executables, vfs is
> > not needed but its linked in anyway. There was an issue with this, as
> > vfs_init() was always called as it's present in the init section of
> > the ELF. Some early executables in the boot process fail in the
> > vfs_init() call as the ramfs is still not available. To solve this, we
> > have placed the
> > vfs_init() call at the start of the programs that use vfs, as most of
> > them don't use it.
> >
> > If you wish I can send you the patch to be included in the tree...
> >
> >
> > Kind regards,
> >
> >
> > --
> > Zeus Gómez Marmolejo
> > Barcelona Supercomputing Center
> > PhD student
> > http://www.bsc.es
> >
> 
> _______________________________________________
> Barrelfish-users mailing list
> Barrelfish-users at lists.inf.ethz.ch
> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users