Google әзірлеушілерінің бірі LLVM жобасының бөлігі ретінде көп платформалы стандартты C кітапханасын (Libc) әзірлеу туралы LLVM тарату тізімінде. Бірқатар себептерге байланысты Google қазіргі libc (glibc, musl) қанағаттандырмайды және компания LLVM бөлігі ретінде әзірлеу ұсынылатын жаңа енгізуді әзірлеу жолында.
Жақында LLVM әзірлемелері Google құрастыру құралдарын құру үшін негіз ретінде пайдаланылды. Негізгі идея, егер Google өзінің libc әзірлеуін бастаған болса, онда C++ (Libc++) үшін өзінің стандартты кітапханасын ұсынатын, бірақ C үшін ұқсас стандартты кітапханасы жоқ LLVM бөлігі ретінде өз жүйесін неге дереу дамытпайды. (libc).
Әзірлеуді функционалдылықты біртіндеп арттыра отырып, кезең-кезеңімен жүзеге асыру жоспарлануда. Бірінші нұсқаларды қолданба мен Libc жүйесі арасындағы қабат ретінде құрастыру ұсынылады, олардан әлі іске асырылмаған мүмкіндіктер алынады. Белгілі бір функционалдық деңгейге жеткеннен кейін жаңа Libc жүйесін Libc жүйесін толық ауыстыру ретінде пайдалануға болады. Біз x86-64 архитектурасына қолдау көрсетуден, Linux және статикалық байланыстырудан бастауды жоспарлап отырмыз (динамикалық жүктеу, байланыстыру және қосымша архитектуралар екінші рет орындалады).
Жоба әлі де дамудың бастапқы кезеңінде, бірақ негізгі мақсаттары анықталған:
- Модульдік және монолитті жинақтан гөрі түйіршікті кітапхананы жеткізу философиясына сәйкес даму;
- Режимдерде статикалық байланыстыруды қолдау (Позицияға тәуелсіз орындалатын файлдар) және PIE жоқ. Статикалық байланысты орындалатын файлдар үшін CRT (C жұмыс уақыты) және PIE жүктеушісін қамтамасыз ету;
- POSIX қосымшаларымен және бар қолданбалар талап ететін кейбір жүйеге тән кеңейтімдермен стандартты C кітапханасының функцияларының көпшілігіне қолдау көрсету;
- Жеткізушіге арналған кеңейтімдермен абай болыңыз және оларды қажет болғанда ғана қосыңыз. Үшінші тарап кеңейтімдерін қолдауға қатысты Clang және libc++ жобаларының тәсілін пайдалану ұсынылады;
- LLVM құралдар жинағын қолдану арқылы әзірлеуде ең жақсы тәжірибелерді пайдалану, мысалы, тазартқышты пайдалану және басынан бастап fuzz тестілеу.
Белсенді LLVM әзірлеушілерінің бірі LLVM құралдар жинағының бөлігі ретінде libc жіберудің мағынасы бар екені анық, бірақ әдетте, мұндай қажеттілік туындаған кезде олар жақсы жазылған, әртүрлі архитектураларды қолдайтын және динамикалық қолдауды қоса алғанда, қажетті функционалдылықты қамтамасыз ететін musl кітапханасын пайдаланады. байланыстыру. LLVM ішіне musl енгізу және оны негізгі жобамен синхрондалған шанышқы ретінде дамыту ақталған болуы мүмкін.
Сіздің де пікіріңіз Google ұсынысы мен Libc-ті LLVM таратуына қосу неліктен өте жаман идея екенін дәлелдеуге тырысқан Musl жобасының авторы:
- Дұрыс, үйлесімді және жоғары сапалы Libc әзірлеу және қолдау өте қиын міндет. Мәселе кодтың көлемінде емес, C/C++ тілінде бұрын-соңды жазылған қолданбалардың үлкен қабатын, сондай-ақ орындалу уақыты пайдаланылатын басқа тілдердегі қолданбаларды ескере отырып, дұрыс әрекетті және интерфейстерді енгізу қиындықтарын қамтамасыз етуде. Libc бойынша. Нюанстарды есепке алмаған бетпе-бет келу көптеген қолданыстағы бағдарламалардың Libc-пен жұмыс істей алмайтындығына әкеледі, бірақ содан кейін мұндай жоба тұтынушыларды қызықтырмайды.
- Корпоративтік даму Libc-ті бұзуы мүмкін, бірақ оны кеңінен қолдану үшін итермелейді, нәтижесінде қолданбаларда үйлесімділікті қамтамасыз ету үшін бұзуды қосу қажет. Корпоративтік ашық бастапқы жобаның қамқорлығындағы даму қоғамның мүдделеріне нұқсан келтіре отырып, компанияның қажеттіліктері мен шешімдеріне қарай тартады. Мысалы, басқа бағдарламадағы қатеден туындаған мәселені анықтасаңыз, басқарылатын әзірлеуде қатенің өзін жөндегеннен гөрі Libc осы қатемен үйлесімді екеніне көз жеткізу оңайырақ. Apple осы мақсаттар үшін BSD libc шанышқыны пайдаланады, ал Google Фуксиядағы musl шанышқыны пайдаланады. musl әзірлеушісінің тәжірибесі лицензиялау мәселелерін түсіндіру үшін оған негізінен заңгерлер хабарласқан, бірақ оның филиалдарына пайдасыз және бұзылатын өзгерістер енгізбес бұрын техникалық мәліметтерді нақтылау үшін ешқашан хабарласпаған.
- libc әзірлеуде мономәдениеттің жоқтығы және жеке бақылауға емес, консенсусқа негізделген стандарттарға назар аудару, бұл қолданбаларды әзірлеушілерді нақты енгізулерге байланысты емес, стандарттарды қолдануға итермелейді. Сондықтан musl авторы өзінің кітапханасын LLVM-ге қосуға қарсы, сондай-ақ LLVM ішінде libc дамуына қарсы, өйткені бұл жағдайда libc тәуелсіз табиғаты жоғалады және белгілі бір іске асыру бірінші дәрежелі шешімге айналады. LLVM және басқалары екінші дәрежелі шешімге айналады.
Ақпарат көзі: opennet.ru