Viens no Google izstrādātājiem, kas LLVM adresātu sarakstā parādīja attīstības tēmu starpplatformu standarta C bibliotēka (Libc) LLVM projekta ietvaros.
Vairāku iemeslu dēļ Google nav apmierināts ar pašreizējo libc (glibc, musl) un uzņēmums ir ceļā, lai izstrādātu jaunu ieviešanu, kuru viņš plāno attīstīt LLVM ietvaros. LLVM izstrādes nesen tika izmantotas kā pamats Google rīku veidošanai.
Plānošana notiek pakāpeniski, pakāpeniski palielinot funkcionalitāti. Tiek ierosināts, ka pirmās iespējas ir starpslāņa veidā starp lietojumprogrammu un libc sistēmu, no kuras tiks aizņemtas nerealizētās funkcijas.
Pēc noteikta funkcionalitātes līmeņa sasniegšanas jauno Libc var izmantot kā pilnīgu Libc sistēmas aizstājēju.
Plānots sākt ar atbalstu x86-64 arhitektūrai, Linux un statiskai saistīšanai (dinamiskā ielāde, iepakošana un papildu arhitektūras tiks ieviestas otrajā vietā).
Projekts joprojām ir izstrādes sākuma stadijā, bet pamatmērķi jau ir noteikti:
- Modularitāte un attīstība saskaņā ar granulētās bibliotēkas piegādes filozofiju, nevis monolīts ansamblis.
- Statisko saišu atbalsts PIE režīmos (no pozīcijas neatkarīgi izpildāmie faili) un bez PIE. Nodrošiniet CRT (C izpildlaika) un PIE iekrāvēju statiski saistītiem izpildāmajiem failiem.
- Atbalsta lielāko daļu C bibliotēkas funkciju standarta ar POSIX spraudņiem un dažiem sistēmai raksturīgiem paplašinājumiem, kas tiek pieprasīti esošajās lietojumprogrammās.
- Rūpīga attieksme pret konkrētiem pagarinājumiem no pakalpojumu sniedzēja un pievienojot tos tikai nepieciešamības gadījumā. Trešās puses paplašinājuma atbalstam tiek piedāvāts izmantot projekta pieeju Clang un libc ++.
- Labākās prakses izmantošana attīstībā, izmantojot LLVM rīkus, piemēram, dezinfekcijas līdzekļu lietošana un testu atcelšana no paša sākuma.
Viens no aktīvajiem LLVM izstrādātājiem to norādīja libc piegāde kā daļa no LLVM rīkkopa ne bez nozīmes, bet parasti ar šādu vajadzību viņi izmanto musl bibliotēku, Tas ir labi uzrakstīts, atbalsta vairākas arhitektūras un nodrošina nepieciešamo funkcionalitāti, ieskaitot dinamisko sasaisti.
Musulma iekļaušanu LLVM un tā attīstību kā sinhronizētu dakšiņu ar galveno projektu var pamatot.
Viņa viedokli pauda arī Musl projekta autors, kurš mēģināja argumentēt, kāpēc Google priekšlikums un Libc iekļaušana LLVM piegādē ir ļoti sliktas idejas:
Pareiza, saderīga un kvalitatīva libc izstrāde un uzturēšana ir ļoti grūts uzdevums. Problēma nav koda daudzumā, bet gan pareizas uzvedības nodrošināšanā.
Un saskarnes ieviešanas grūtības, ņemot vērā milzīgo C / C ++ rakstīto lietojumprogrammu krātuvi, kā arī lietojumprogrammas citās valodās, kuru izpildlaiku izmanto Libc.
Pieeja uz pieres, neņemot vērā nianses, novedīs tikai pie tā, ka daudzas esošās programmas nevarēs strādāt ar Libc, taču šāds projekts patērētājus neinteresēs.
Korporatīvā attīstība var sabojāt Libc, bet veicina plašu lietošanu, kā rezultātā būs jāpievieno uzlaušana, lai nodrošinātu saderību lietojumprogrammās.
Attīstība atklātā korporatīvā projekta paspārnē veicinās uzņēmuma vajadzības un lēmumus, kaitējot sabiedrības interesēm.
Piemēram, ja tiek identificēta problēma, ko izraisījusi kļūda citā jūsu pašu programmā, kontrolētajā izstrādē ir vieglāk garantēt Libc saderību ar šo kļūdu, nekā labot pašu kļūdu.
Šiem nolūkiem Apple izmanto BSD libc dakšu, bet Google - Fuksijas dakšiņu. Musl izstrādātāju pieredze liecina, ka juristi galvenokārt ar viņu sazinājās, lai noskaidrotu licencēšanas jautājumus.
Fuente: http://lists.llvm.org