Hi Wink, As you've observed in that commit, removing the libc dependency leads you to re-implement pieces of it inline. We used to do something similar to this, but replaced this with an explicit dependency on libc to avoid complications with multiple definitions of typedefs and such. In the case of programmer error, these typedefs may not match and if the conflicting typedefs are never seen within the same translation unit your compiler will not notice either. The end result was subtle bugs arising from ABI incompatibility.
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. Cheers, Matt On 23/06/15 11:16, Wink Saville wrote:
I noticed that seL4/libsel4 was dependent upon libc and so I created a patch (https://github.com/winksaville/seL4/commit/fc91a1f68c054fdb41aaa42a7b56a80f481b68b2) which removes the dependency. If there is interest I can submit a pull request, and of course will make any changes deemed necessary to make it suitable for acceptance. Please advise, Wink _______________________________________________ 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
