[Barrelfish-users] Newlib libc ported

["Vicenç Beltran (AC)"]

Dear Mothy,
newlib is  developed under set of BSD-like or public domain licenses. 
All the licenses used are in this link: 
http://sourceware.org/newlib/COPYING.NEWLIB

There are a few files under the GPL or LGPL license but these files are 
used only on the *-linux targets and iconv library, which is optional.
Anyway, we will double-check the license of all the files required to 
build the Newlib on Barrelfish.

Regards,
  - Vicenç

On 19/12/2011 17:43, Timothy Roscoe wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20111219/74e141a9/attachment.html