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 [[email protected]] on behalf of Justin Cormack [[email protected]] Sent: Monday, 29 June 2015 20:41 To: Matthew Fernandez Cc: [email protected] Subject: Re: [seL4] Make seL4/libsel4 not depend upon libc On 23 June 2015 at 08:02, Matthew Fernandez <[email protected]> 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 [email protected] 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. _______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
