हमारे पास स्थिर पुस्तकालयों में एक कोड आधार टूट गया है। दुर्भाग्यवश, पुस्तकालयों में परिपत्र निर्भरताएं हैं; उदाहरण के लिए, libfoo.alibbar.a और इसके विपरीत पर निर्भर करता है।एक ही लाइब्रेरी को दो बार जोड़कर परिपत्र निर्भरताओं को हल करना?
g++ -o myApp -Wl,--start-group -lfoo -lbar -Wl,--end-group
लेकिन हमारे मौजूदा Makefiles में, समस्या आम तौर पर इस तरह नियंत्रित किया जाता है:
मैं "सही" जिस तरह से यह इतना तरह लिंकर की --start-group और --end-group विकल्पों का उपयोग करने, है संभाल करने के लिए पता
g++ -o myApp -lfoo -lbar -lfoo
(कल्पना कीजिए यह करने के लिए ~ परिसर के साथ बढ़ाया 20 पुस्तकालयों।)
मैं कहां से गुजर रही किया गया है आर मेकफ़ाइल पहले फॉर्म को दूसरे रूप में बदल रहा है, लेकिन अब मेरे सहकर्मी मुझसे पूछ रहे हैं क्यों ... और "क्योंकि यह क्लीनर" और अस्पष्ट भावना है कि दूसरा रूप जोखिम भरा है, मेरे पास कोई अच्छा जवाब नहीं है।
तो, एक ही लाइब्रेरी को कई बार लिंक कर सकते हैं कोई समस्या पैदा करें? उदाहरण के लिए, क्या लिंक गुणा-परिभाषित प्रतीकों के साथ विफल हो सकता है यदि वही .o दो बार खींच लिया जाता है? या क्या कोई जोखिम है जो हम एक ही स्थैतिक वस्तु की दो प्रतियों के साथ हवादार हो सकते हैं, सूक्ष्म बग बना सकते हैं?
असल में, मैं जानना चाहता हूं कि लिंक लाइफ या रन-टाइम विफलताओं की संभावना है कि एक ही लाइब्रेरी को कई बार लिंक करने से हो; और यदि हां, तो उन्हें कैसे ट्रिगर करें। धन्यवाद।
एकमात्र समस्या जिसे मैं सोच सकता हूं वह तब होता है जब आप उसी लाइब्रेरी के दो अलग-अलग संस्करणों से लिंक करते हैं। ऐसा करना मुश्किल है और (आईएमओ) लिनक्स पर होने की संभावना नहीं है। इसके अलावा, केवल 20 पुस्तकालयों की तरह दिखता नहीं है। क्या मेकफ़ाइल के माध्यम से चलना उचित है? आप उस समय कुछ और कर सकते हैं। – SigTerm
यदि आप अपनी पुस्तकालयों को परिपत्र निर्भरता नहीं रखते हैं तो यह समस्या अभी दूर हो जाती है। –
मुझे लगता है कि पुस्तकालयों की जांच और तोड़कर सर्कुलर निर्भरता को दूर करना संभव नहीं है? क्योंकि यह सबसे साफ तरीका होगा –