The main driving force for the libsel4->libc dependency was compile issues caused by conflicting header guards when libsel4 provided its own type definitions. If the header guards did not conflict, there were issues with duplicate definitions. When they did conflict, the actual file that was included depended on the order of compile arguments. To add to this, the conflicts depended heavily on which c library was deployed. The rationale was a lot weaker than assuming that the developer would have a libc handy. At the time, only standard type definitions were required (from stdint.h). It was assumed that a developer could easily provide their own stdint.h if they chose not to use a c library. - Alex ________________________________________ From: Devel [devel-bounces@sel4.systems] on behalf of Justin Cormack [justin@specialbusservice.com] Sent: Monday, 29 June 2015 20:41 To: Matthew Fernandez Cc: devel@sel4.systems Subject: Re: [seL4] Make seL4/libsel4 not depend upon libc On 23 June 2015 at 08:02, Matthew Fernandez <matthew.fernandez@nicta.com.au> wrote:
When we made the change, out rationale was that anyone using the syscall stubs would have libc available anyway. This certainly introduces a circular dependency, but it's not easy to remove without repeating parts of one library in the other or playing tricks with externs and weak symbols. In my experience, all of this is more fragile and less preferable than living with the circular dependency. However, my opinion may not be universally shared as we haven't had a discussion about this for some time.
There are many cases where you may want syscalls and not libc, for example several programming languages use direct bindings not bindings via libc (eg Go). I am interested in porting a different libc, and while the bits needed may well be ABI compatible it is hard to tell. So I would much rather the syscall stubs could be used standalone without a libc. Justin _______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel ________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.