Isa sa mga developer mula sa Google sa LLVM mailing list tungkol sa pagbuo ng isang multi-platform standard C library (Libc) bilang bahagi ng proyekto ng LLVM. Para sa ilang kadahilanan, hindi nasisiyahan ang Google sa kasalukuyang libc (glibc, musl) at ang kumpanya ay patungo sa pagbuo ng isang bagong pagpapatupad, na iminungkahing i-develop bilang bahagi ng LLVM.
Ang mga pagpapaunlad ng LLVM ay ginamit kamakailan bilang batayan para sa pagbuo ng mga tool sa pagpupulong ng Google. Ang pangunahing ideya ay kung sinimulan na ng Google na bumuo ng libc nito, bakit hindi kaagad bumuo ng system nito bilang bahagi ng LLVM, na nag-aalok na ng sarili nitong karaniwang library para sa C++ (Libc++), ngunit walang katulad na standard library para sa C (libc).
Ang pag-unlad ay binalak na isagawa sa mga yugto, unti-unting pagtaas ng pag-andar. Ang mga unang opsyon ay iminungkahi na idisenyo bilang isang layer sa pagitan ng application at ng system Libc, kung saan hihiramin ang mga feature na hindi pa naipapatupad. Pagkatapos maabot ang isang tiyak na antas ng functionality, ang bagong Libc ay maaaring gamitin bilang isang kumpletong kapalit para sa system na Libc. Plano naming magsimula sa suporta para sa x86-64 na arkitektura, Linux, at static na pag-link (ang dynamic na pag-load, pag-link, at mga karagdagang arkitektura ay ipapatupad sa pangalawa).
Ang proyekto ay nasa unang yugto pa ng pag-unlad, ngunit ang mga pangunahing layunin ay natukoy na:
- Modularity at pag-unlad alinsunod sa pilosopiya ng paghahatid ng butil-butil na aklatan sa halip na isang monolitikong hanay;
- Suporta para sa static na pag-link sa mga mode (Position-independent executables) at walang PIE. Nagbibigay ng CRT (C runtime) at PIE loader para sa statically linked executables;
- Suporta para sa karamihan ng mga karaniwang function ng C library, na may mga karagdagan ng POSIX at ilang mga extension na partikular sa system na kinakailangan ng mga umiiral na application;
- Mag-ingat sa mga extension na partikular sa vendor at idagdag lang ang mga ito kapag kinakailangan. Tungkol sa suporta para sa mga extension ng third-party, iminungkahi na gamitin ang diskarte ng mga proyekto ng Clang at libc++;
- Paggamit ng pinakamahuhusay na kagawian sa pag-unlad gamit ang LLVM toolkit, gaya ng paggamit ng sanitizer at fuzz testing mula sa simula.
Isa sa mga aktibong developer ng LLVM Malinaw na makatuwirang ipadala ang libc bilang bahagi ng toolkit ng LLVM, ngunit kadalasan, kapag may ganoong pangangailangan, ginagamit nila ang musl library, na mahusay ang pagkakasulat, sumusuporta sa iba't ibang arkitektura, at nagbibigay ng kinakailangang functionality, kabilang ang suporta para sa dinamikong pag-uugnay. Maaaring makatwiran na i-embed ang musl sa LLVM at i-develop ito bilang isang tinidor na naka-synchronize sa pangunahing proyekto.
Opinyon mo rin Ang may-akda ng proyektong Musl, na sinubukang magtalo kung bakit ang panukala ng Google at ang pagsasama ng Libc sa pamamahagi ng LLVM ay napakasamang ideya:
- Ang pagbuo at pagpapanatili ng tama, tugma, at mataas na kalidad na Libc ay isang napakahirap na gawain. Ang problema ay wala sa dami ng code, ngunit sa pagtiyak ng tamang pag-uugali at kahirapan sa pagpapatupad ng mga interface, na isinasaalang-alang ang malaking layer ng mga application na naisulat sa C/C++, pati na rin ang mga application sa iba pang mga wika, ang runtime na ginagamit. ni Libc. Ang isang head-on na diskarte nang hindi isinasaalang-alang ang mga nuances ay hahantong lamang sa katotohanan na maraming umiiral na mga programa ang hindi makakatrabaho sa Libc, ngunit pagkatapos ay ang naturang proyekto ay hindi magiging interesado sa mga mamimili.
- Maaaring sirain ng corporate development ang Libc, ngunit itulak ito para sa malawakang paggamit, na nagreresulta sa pangangailangang magdagdag ng mga hack upang matiyak ang pagiging tugma sa mga application. Ang pag-unlad sa ilalim ng suporta ng isang corporate open source na proyekto ay hahatakin ang kumot tungo sa mga pangangailangan at solusyon ng kumpanya, sa kapinsalaan ng mga interes ng komunidad. Halimbawa, kung matukoy mo ang isang problema na sanhi ng isang bug sa isa pang program, sa kinokontrol na pag-unlad, mas madaling matiyak na ang Libc ay tugma sa bug na ito kaysa ayusin ang bug mismo. Ginagamit ng Apple ang BSD libc fork para sa mga layuning ito, at ginagamit ng Google ang musl fork sa Fuchsia. Ang karanasan ng developer ng musl ay na siya ay nakipag-ugnayan pangunahin sa pamamagitan ng mga abogado upang linawin ang mga isyu sa paglilisensya, ngunit hindi kailanman nakipag-ugnayan upang linawin ang mga teknikal na detalye bago gumawa ng walang silbi at nakakagambalang mga pagbabago sa kanyang mga sangay.
- Ang kawalan ng monoculture sa pagbuo ng libc at isang pagtuon sa mga pamantayang batay sa pinagkasunduan kaysa sa tanging kontrol, na nag-uudyok sa mga developer ng application na gumamit ng mga pamantayan sa halip na maugnay sa mga partikular na pagpapatupad. Iyon ang dahilan kung bakit ang may-akda ng musl ay laban sa pagsasama ng kanyang library sa LLVM, pati na rin laban sa pagbuo ng libc sa loob ng LLVM, dahil sa kasong ito ang independiyenteng kalikasan ng libc ay nawala at ang isang tiyak na pagpapatupad ay nagiging isang unang-klase na solusyon para sa Ang LLVM, at lahat ng iba pa ay naging pangalawang-klase na solusyon.
Pinagmulan: opennet.ru