2012-05-14 17 views
5

के खोज आदेश के बारे में कुछ प्रश्न मेरे पास जीसीसी लिंक ऑर्डर के बारे में कुछ प्रश्न हैं। जीसीसी मैन डिफ़ॉल्ट रूप से बार-बार खोज किए बिना बाएं से दाएं लिंकर खोज प्रतीकों का कहना है। यहाँ मेरी परीक्षा है:जीसीसी लिंकर

main.c

#include <stdio.h> 
#include <stdlib.h> 

int main() 
{ 
     printf("HELLO WROLD\n"); 
     return 0; 
} 

printf.c

#include <stdio.h> 
#include <stdlib.h> 

int printf(const char *fmt, ...) 
{ 
     write(1, "AAA\n", 4); 
} 

[[email protected] testcode]# gcc -c -fno-builtin-printf *.c 
[[email protected] testcode]# gcc -o test main.o printf.o 
[[email protected] testcode]# ./test 
AAA 
[[email protected] testcode]# gcc -o test printf.o main.o 
[[email protected] testcode]# ./test 
AAA 


[[email protected] testcode]# ar rcs libprintf.a printf.o 
[[email protected] testcode]# gcc -o test libprintf.a main.o 
[[email protected] testcode]# ./test 
HELLO WROLD 
[[email protected] testcode]# gcc -o test main.o libprintf.a 
[[email protected] testcode]# ./test 
AAA 


[[email protected] testcode]# gcc -shared -o libprintf.so printf.o 
[[email protected] testcode]# gcc -o test libprintf.so main.o 
[[email protected] testcode]# export LD_LIBRARY_PATH=. 
[[email protected] testcode]# ./test 
AAA 
[[email protected] testcode]# gcc -o test main.o libprintf.so 
[[email protected] testcode]# ./test 
AAA 

परिणाम से, हम ओ और ओ, ओ और के आदेश देख सकते हैं .so कोई फर्क नहीं पड़ता, केवल .o और .a का ऑर्डर प्रभाव पड़ता है। लेकिन यह जीसीसी मैन पेज के साथ असंगत है। तो क्यों?

+0

मैंने -v का उपयोग किया है, लेकिन फिर भी मुझे समझ में नहीं आता क्यों। क्या आप इसे विस्तार से समझा सकते हैं? – D3Hunter

+0

मैं -nodefaultlibs का उपयोग नहीं कर सकता, क्योंकि crst में कुछ फ़ंक्शंस जैसे _start मौजूद होना चाहिए। – D3Hunter

+0

मुझे लगता है कि मैं टीएल; डीआर-एड पहले। आपको लगता है कि 'यह' जीसीसी एमएन पृष्ठ के साथ असंगत है? – sehe

उत्तर

8

जीसीसी वास्तव में ऑब्जेक्ट फ़ाइलों को बाएं से दाएं संसाधित करता है। जब आप

gcc -o test libprintf.a main.o 

है पहली वस्तु फ़ाइल जीसीसी देखता libprintf.a है। इस बिंदु पर आउटपुट ऑब्जेक्ट के लिए कोई अनसुलझे प्रतीक नहीं हैं, इसलिए libprintf.a से कुछ भी उपयोग/आवश्यक नहीं है। अगला, main.o संसाधित किया गया है, लिंकर इस तथ्य का एक नोट बनाता है कि printf अनसुलझा है, और उसके बाद निहित पुस्तकालयों को संसाधित करने के लिए आगे बढ़ता है जहां यह printf प्रतीक को हल करने में सक्षम है जो in main.o अनसुलझा था।

इसी तरह

, जब आपके पास:

gcc -o test main.o libprintf.a 

पहली वस्तु फ़ाइल संसाधित करने के लिए main.o, जहां अनसुलझे प्रतीक printf विख्यात है, अगला संसाधित करने के लिए libprintf.a जहाँ से लिंकर को हल करने में सक्षम है printflibc को अंततः संसाधित किया जाता है, printf पहले से ही हल हो चुका है इसलिए का उदाहरण libc में उपयोग नहीं किया जाता है।

जब ओ फाइलों के साथ जोड़ने:

gcc -o test main.o printf.o 

libc पुस्तकालय फिर से इलाज किया जैसे कि वह कमांड लाइन के अंत में निर्दिष्ट किया गया था है, इसलिए printf प्रतीक हल हो गई है से पहले (बाएँ-से राइट) ऑब्जेक्ट फ़ाइल जो इसे परिभाषित करती है।

libprintf.so दोनों स्थितियों के लिए, libc पुस्तकालय फिर से इलाज किया जैसे कि वह कमांड लाइन के अंत में निर्दिष्ट किया गया था है। स्थिर लाइब्रेरी मामले से अलग क्या है कि *.so पुस्तकालयों के बाएं से दाएं ऑर्डरिंग रन-टाइम डायनामिक प्रतीक खोज ऑर्डर निर्धारित करता है। चूंकि इस आदेश में libprintf.so अंतर्निहित libc.so से पहले है, में printf का संस्करण उपयोग किया जाता है।

gcc -o test libprintf.so main.o 
gcc -o test main.o libprintf.so 

एक अतिरिक्त प्रयोग के रूप में, आप की कोशिश कर सकते:

gcc -o test main.o -lc libprintf.so 

यह printf के संस्करण दिखाना चाहिए libc.so बजाय libprintf.so से इस्तेमाल किया जा रहा है क्योंकि -lc बाएँ से सही क्रम में libprintf.so पहले आता है।

+0

तो क्यों करें .o और .o, .o और .so काम नहीं करते? – D3Hunter

+0

इन मामलों के लिए स्पष्टीकरण जोड़ने के लिए संपादित ... प्रारंभिक प्रतिक्रिया में उन लोगों की उपेक्षा करने के लिए खेद है। –

संबंधित मुद्दे