Google నుండి డెవలపర్లు LLVM కోసం వారి స్వంత libcని అభివృద్ధి చేయాలని సూచించారు
Google నుండి డెవలపర్లలో ఒకరు పెంచారు LLVM ప్రాజెక్ట్లో భాగంగా బహుళ-ప్లాట్ఫారమ్ ప్రామాణిక C లైబ్రరీ (Libc) అభివృద్ధి గురించి LLVM మెయిలింగ్ జాబితాలో. అనేక కారణాల వల్ల, Google ప్రస్తుత libc (glibc, musl)తో సంతృప్తి చెందలేదు మరియు కంపెనీ LLVMలో భాగంగా అభివృద్ధి చేయడానికి ప్రతిపాదించబడిన కొత్త అమలును అభివృద్ధి చేసే మార్గంలో ఉంది.
LLVM డెవలప్మెంట్లు ఇటీవల Google యొక్క అసెంబ్లీ సాధనాలను రూపొందించడానికి ఆధారంగా ఉపయోగించబడ్డాయి. ప్రధాన ఆలోచన ఏమిటంటే, Google ఇప్పటికే దాని libcని అభివృద్ధి చేయడం ప్రారంభించినట్లయితే, LLVMలో భాగంగా దాని సిస్టమ్ను వెంటనే ఎందుకు అభివృద్ధి చేయకూడదు, ఇది ఇప్పటికే C++ (Libc++) కోసం దాని స్వంత ప్రామాణిక లైబ్రరీని అందిస్తోంది, కానీ C కోసం ఇదే విధమైన ప్రామాణిక లైబ్రరీ లేదు. (libc).
అభివృద్ధి దశల్లో నిర్వహించబడాలని యోచిస్తున్నారు, క్రమంగా కార్యాచరణను పెంచుతుంది. మొదటి ఎంపికలు అప్లికేషన్ మరియు సిస్టమ్ Libc మధ్య లేయర్గా రూపొందించబడాలని ప్రతిపాదించబడ్డాయి, దీని నుండి ఇంకా అమలు చేయని ఫీచర్లు తీసుకోబడతాయి. ఫంక్షనాలిటీ యొక్క నిర్దిష్ట స్థాయికి చేరుకున్న తర్వాత, కొత్త Libc సిస్టమ్ Libcకి పూర్తి ప్రత్యామ్నాయంగా ఉపయోగించబడుతుంది. మేము x86-64 ఆర్కిటెక్చర్, లైనక్స్ మరియు స్టాటిక్ లింకింగ్ (డైనమిక్ లోడింగ్, లింకింగ్ మరియు అదనపు ఆర్కిటెక్చర్లు ద్వితీయంగా అమలు చేయబడతాయి) మద్దతుతో ప్రారంభించాలని ప్లాన్ చేస్తున్నాము.
ప్రాజెక్ట్ ఇంకా అభివృద్ధి ప్రారంభ దశలోనే ఉంది, అయితే ప్రాథమిక లక్ష్యాలు ఇప్పటికే నిర్వచించబడ్డాయి:
మోనోలిథిక్ సెట్ కాకుండా గ్రాన్యులర్ లైబ్రరీని అందించే తత్వశాస్త్రానికి అనుగుణంగా మాడ్యులారిటీ మరియు అభివృద్ధి;
తో మోడ్లలో స్టాటిక్ లింకింగ్కు మద్దతు PIE (స్థానం-ఇండిపెండెంట్ ఎక్జిక్యూటబుల్స్) మరియు PIE లేకుండా. స్థిరంగా లింక్ చేయబడిన ఎక్జిక్యూటబుల్స్ కోసం CRT (C రన్టైమ్) మరియు PIE లోడర్ను అందించడం;
ఇప్పటికే ఉన్న అప్లికేషన్లకు అవసరమైన POSIX జోడింపులు మరియు కొన్ని సిస్టమ్-నిర్దిష్ట పొడిగింపులతో చాలా ప్రామాణిక C లైబ్రరీ ఫంక్షన్లకు మద్దతు;
విక్రేత-నిర్దిష్ట పొడిగింపులతో జాగ్రత్తగా ఉండండి మరియు అవసరమైనప్పుడు మాత్రమే వాటిని జోడించండి. మూడవ పక్షం పొడిగింపులకు మద్దతు గురించి, క్లాంగ్ మరియు libc++ ప్రాజెక్ట్ల విధానాన్ని ఉపయోగించాలని ప్రతిపాదించబడింది;
LLVM టూల్కిట్ని ఉపయోగించి డెవలప్మెంట్లో ఉత్తమ పద్ధతులను ఉపయోగించడం, ఉదాహరణకు శానిటైజర్ను ఉపయోగించడం మరియు మొదటి నుండి ఫజ్ టెస్టింగ్ చేయడం వంటివి.
క్రియాశీల LLVM డెవలపర్లలో ఒకరు ఎత్తి చూపారుLLVM టూల్కిట్లో భాగంగా libcని రవాణా చేయడం సమంజసమని స్పష్టంగా చెప్పవచ్చు, అయితే సాధారణంగా, అలాంటి అవసరం వచ్చినప్పుడు, వారు musl లైబ్రరీని ఉపయోగిస్తారు, ఇది బాగా వ్రాయబడింది, వివిధ నిర్మాణాలకు మద్దతు ఇస్తుంది మరియు డైనమిక్కు మద్దతుతో సహా అవసరమైన కార్యాచరణను అందిస్తుంది. లింకింగ్. LLVMలో మస్ల్ను పొందుపరచడం మరియు ప్రధాన ప్రాజెక్ట్తో సమకాలీకరించబడిన ఫోర్క్గా అభివృద్ధి చేయడం సమర్థించబడవచ్చు.
మీ అభిప్రాయం కూడా వ్యక్తపరచబడిన LLVM పంపిణీలో Google ప్రతిపాదన మరియు Libcని ఎందుకు చేర్చడం చాలా చెడ్డ ఆలోచనలు అని వాదించడానికి ప్రయత్నించిన Musl ప్రాజెక్ట్ రచయిత:
సరైన, అనుకూలమైన మరియు అధిక-నాణ్యత గల Libcని అభివృద్ధి చేయడం మరియు నిర్వహించడం చాలా కష్టమైన పని. సమస్య కోడ్ మొత్తంలో కాదు, సరైన ప్రవర్తన మరియు ఇంటర్ఫేస్లను అమలు చేయడంలో ఇబ్బందులను నిర్ధారించడంలో, C/C++లో ఇప్పటివరకు వ్రాసిన అప్లికేషన్ల యొక్క భారీ పొరను, అలాగే ఇతర భాషలలోని అప్లికేషన్లను పరిగణనలోకి తీసుకుంటుంది, దీని రన్టైమ్ ఉపయోగించబడుతుంది. Libc ద్వారా. సూక్ష్మ నైపుణ్యాలను పరిగణనలోకి తీసుకోకుండా ఒక తలపై ఉన్న విధానం ఇప్పటికే ఉన్న అనేక ప్రోగ్రామ్లు Libcతో పని చేయలేకపోవడానికి దారి తీస్తుంది, అయితే అలాంటి ప్రాజెక్ట్ వినియోగదారులకు ఆసక్తిని కలిగించదు.
కార్పొరేట్ డెవలప్మెంట్ Libcని నాశనం చేయగలదు, కానీ విస్తృతమైన ఉపయోగం కోసం దీనిని పుష్ చేస్తుంది, దీని ఫలితంగా అప్లికేషన్లలో అనుకూలతను నిర్ధారించడానికి హ్యాక్లను జోడించాల్సిన అవసరం ఏర్పడుతుంది. కార్పొరేట్ ఓపెన్ సోర్స్ ప్రాజెక్ట్ ఆధ్వర్యంలోని అభివృద్ధి సంస్థ యొక్క అవసరాలు మరియు పరిష్కారాల వైపు కంబళిని లాగి, సంఘం ప్రయోజనాలకు హాని కలిగిస్తుంది. ఉదాహరణకు, మీరు మరొక ప్రోగ్రామ్లోని బగ్ వల్ల ఏర్పడే సమస్యను గుర్తిస్తే, నియంత్రిత అభివృద్ధిలో, బగ్ను పరిష్కరించడం కంటే Libc ఈ బగ్తో అనుకూలంగా ఉందని నిర్ధారించుకోవడం సులభం. Apple ఈ ప్రయోజనాల కోసం BSD libc ఫోర్క్ని ఉపయోగిస్తుంది మరియు Google Fuchsiaలో మస్ల్ ఫోర్క్ని ఉపయోగిస్తుంది. మస్ల్ డెవలపర్ యొక్క అనుభవం ఏమిటంటే, అతను ప్రధానంగా లైసెన్సింగ్ సమస్యలను స్పష్టం చేయడానికి న్యాయవాదులచే సంప్రదించబడ్డాడు, కానీ అతని శాఖలలో పనికిరాని మరియు అంతరాయం కలిగించే మార్పులు చేసే ముందు సాంకేతిక వివరాలను స్పష్టం చేయడానికి ఎప్పుడూ సంప్రదించలేదు.
libc డెవలప్మెంట్లో మోనోకల్చర్ లేకపోవడం మరియు ఏకైక నియంత్రణ కంటే ఏకాభిప్రాయంతో నడిచే ప్రమాణాలపై దృష్టి పెట్టడం, ఇది నిర్దిష్ట అమలులతో ముడిపడి ఉండకుండా ప్రమాణాలను ఉపయోగించడానికి అప్లికేషన్ డెవలపర్లను ప్రేరేపిస్తుంది. అందుకే musl రచయిత తన లైబ్రరీని LLVMలో చేర్చడాన్ని వ్యతిరేకించాడు, అలాగే LLVMలో libc అభివృద్ధికి వ్యతిరేకంగా ఉన్నాడు, ఎందుకంటే ఈ సందర్భంలో libc యొక్క స్వతంత్ర స్వభావాన్ని కోల్పోతారు మరియు ఒక నిర్దిష్ట అమలుకు ఫస్ట్-క్లాస్ పరిష్కారం అవుతుంది. LLVM, మరియు మిగతావన్నీ రెండవ-తరగతి పరిష్కారంగా మారతాయి.