One of the Google developers presented on the LLVM mailing list the topic of developing a cross-platform standard C library (Libc) within the framework of the LLVM project.
For several reasons, Google is not satisfied with the current libc (glibc, musl) and the company is on track to develop a new implementation, which he intends to develop as part of LLVM. LLVM developments have recently been used as the basis for building Google tools.
Development is planned to be gradual, gradually increasing functionality. It is proposed that the first options take the form of an intermediate layer between the application and the libc system, from which the unrealized features will be borrowed.
After reaching a certain level of functionality, the new Libc can be used as a complete replacement for the Libc system.
It is planned to start with support for the x86-64 architecture, Linux, and static binding (dynamic loading, packaging, and additional architectures will be implemented second).
The project is still in the initial stage of development, but the basic objectives have already been defined:
- Modularity and development in accordance with the philosophy of supplying a granular library, rather than a monolithic ensemble.
- Static link support in PIE modes (position-independent executables) and without PIE. Provide CRT (C Runtime) and PIE loader for statically linked executable files.
- Supports most of the C library functions standard with POSIX plug-ins and some system-specific extensions that are requested in existing applications.
- Careful attitude towards specific extensions from the provider and only adding them when necessary. For third-party extension support, it is proposed to use the Clang and libc ++ project approach.
- Using Best Practices in Development Using LLVM Tools, such as the application of disinfectants and the elimination of tests from the beginning.
One of the active LLVM developers indicated that libc delivery as part of LLVM toolkit it is not without meaning, but generally with such a need they use the musl library, It is well written, supports multiple architectures, and provides the necessary functionality, including dynamic linking.
The incorporation of Musl into LLVM and its development as a synchronized fork with the main project can be justified.
His opinion was also expressed by the author of the Musl project, who tried to argue why Google's proposal and the inclusion of Libc in the LLVM delivery are very bad ideas:
Developing and maintaining the correct, compatible and high-quality libc is a very difficult task. The problem is not in the amount of code, but in providing the correct behavior.
And the difficulties with interface implementation, considering the huge repository of applications written in C / C ++, as well as applications in other languages whose runtime is used by Libc.
The approach to the forehead without taking into account the nuances will only lead to the fact that many existing programs will not be able to work with Libc, but such a project will not be of interest to consumers.
Corporate development can ruin Libc, but drive widespread use, which will result in the need to add hacks to ensure compatibility in applications.
Development under the auspices of a corporate open project will drive coverage towards the needs and decisions of the company, to the detriment of the interests of the community.
For example, in the case of identifying a problem caused by an error in another program of your own, in the development under control, it is easier to guarantee the compatibility of Libc with this error than to correct the error itself.
Apple uses the BSD libc fork for these purposes and Google uses the Fuchsia fork. Musl's developer experience suggests that the lawyers contacted him primarily to clarify the licensing issues.
Source: http://lists.llvm.org