[Barrelfish-users] New version of glibc?

[Robert Radkiewicz]

Hi,

I managed to get the newlib into the barrelfish-tree and compiling it 
with hake, but the problems arise when parts of barrelfish are compiled 
and the definitions of functions or variables don't fit together. I'm 
not an expert in the libc, I'm just using it, so I think I have to shift 
that part to the future for the moment.
I am even unsure, if the problem I had in the first place would be 
solved, because I stepped over some compiling errors there.

I get some wrong values when printing (!) 64 bit characters which are 
lying on the stack, the lower or upper 32 bits maybe cluttered. Printing 
it 32-bit wise works. I guess some of the definitions for the data type 
are not consistent, because I need to specify an "l" as printf-argument 
for printing a uint32_t variable, which should not be necessary. The 
sizeof-from all the types give the expected values. So far I did not 
notice any wrong calculations with 64bit-values.

Any suggestions where to search?

Thanks,
Robert

On 19.10.2012 11:39, Kornilios Kourtis wrote:
> As you might already know, we 've recently switched to using newlib as
> our default libc (this was based on work done by Zeus Gómez Marmolejo).
> Currently, the tree contains the old C library (oldc) as well. This will
> make your porting effort easier, since libc is now separated from the
> rest of the system.
>
> Here are a couple of things to get you started:
>
>   - You will need to incorporate your library to the barrelfish building
>     system (hake). This means to two things: a) building your libc using
>     hake, and b) building barrelfish programs using your libc.
>
>     The latter is probably the easy part: See Config.libc/Config.libcInc
>     variables in hake/Config.hs[1]. Library "/lib/lib" ++ Config.libc ++
>     ".a" is linked to all applications. [2]
>
>     For the former part, you will need to use hake for building your libc.
>     You might be able to avoid that part and build it externally, but I'm
>     not sure if this is the better option in the long term. Good starting
>     points are oldc's and newlib's Hakefiles.
>
> - You will need to implement the necessary OS glue that is needed by
>    libc. For the most part, this glue deals with file access (stdio) and
>    memory management (malloc and friends). Barrelfish is not a Unix OS,
>    so this presents some challenges.  An approach would be to have libc
>    build on top of posixcompat layer, which provides (at some degree) what
>    a C library would expect from a Unix OS. The problem with this is that
>    it requires all barrelfish programs be linked to posixcompat and
>    friends, since all programs use libc. Since we didn't like that, the
>    libcs included in our tree do not dependent to posixcompat, and they
>    contain a glue layer to allow things like file access, only if the
>    appropriate libraries are linked in. The code for newlib glue exists in
>    the lib/newlib/newlib/libc/sys/barrelfish directory.
>
> [1] A barrelfish build is configured using hake/Config.hs in the build
> directory which is created based on hake/Config.hs.template in the source
> directory.
>
> [2] This happens in hake/ArchDefaults.hs
>