Symbol resolution — order matters — Hinglish notes

5.3.5 · Coding › Build Systems & Toolchain

Symbol resolution KYA hai?

Har object file ke symbol table mein do cheezein hoti hain:

Defined symbols (yeh .o inhe provide karta hai) — function/global yahan rehta hai.
Undefined symbols (yeh .o inhe chahiye) — kisi aur ko supply karna hoga.

Linker ka kaam: end tak undefined symbols ka set khaali kar dena.

Order KYU matter karta hai? (Algorithm, derive karke)

Linker teen sets maintain karta hai jab woh inputs ko left → right scan karta hai:

$E$ — object files ka set jo executable mein jaayenge.
$U$ — abhi ke undefined symbols ka set.
$D$ — $E$ mein files dwara pehle se define kiye gaye symbols ka set.

Sabse zaroori clause: archive ko sirf us $U$ ke against search kiya jaata hai jo linker ke us tak pahunchne par exist karta hai. Symbols jo baad mein undefined ban jaate hain (kyunki koi object aur right mein hai) woh abhi $U$ mein nahi the, isliye archive — jo pehle hi pass ho chuka hai — dobara kabhi nahi dekha jaata.

Consequence (woh rule jo yaad karna hai):

Objects pehle daalo, phir libraries; aur library ko us har object ke baad daalo jo use karta hai. Agar library A, library B use karti hai, toh ... A B likho (user, phir dependency).

Figure — Symbol resolution — order matters

HOW yeh kaam karta hai — worked examples

Worked example Example 1 — classic failure

$ gcc main.o -lm        # main.o calls sqrt(); -lm = libm.a

Trace:

main.o padha → $E = {main}$ , main define karta hai, sqrt reference karta hai → $U = {s q r t}$ .
libm.a padha → member sqrt.o sqrt ∈ $U$ define karta hai → usse pull in karo. $U = \emptyset$ . ✅

Yeh step kyun? sqrt undefined tha pehle se jab hum libm tak pahunche, isliye libm ko us ke liye search kiya gaya. Ab order flip karo:

$ gcc -lm main.o        # WRONG

Pehle libm.a padha → $U = \emptyset$ , isliye koi member pull nahi hota.
main.o padha → ab $U = {s q r t}$ — lekin libm pehle hi peeche reh gaya. ❌ undefined reference to 'sqrt'.

Worked example Example 2 — do static libs ke beech circular dependency

libfoo.a libbar.a ko call karta hai, aur libbar.a libfoo.a ko wapas call karta hai.

$ gcc main.o -lfoo -lbar          # may fail

Maano -lbar ek aisa member pull karta hai jise libfoo se ek naya symbol chahiye. Lekin libfoo pehle hi scan ho chuka hai → woh symbol undefined rehta hai. Fix: libraries repeat karo ya unhe group karo:

$ gcc main.o -lfoo -lbar -lfoo               # repeat
$ gcc main.o -Wl,--start-group -lfoo -lbar -Wl,--end-group   # better

Yeh step kyun? --start-group/--end-group ld ko kehta hai ki enclosed archives ko repeatedly re-scan karo jab tak koi naya member pull na ho — jaanboojhkar one-pass rule ko defeat karta hai.

Worked example Example 3 — koi needed object kyun drop ho gaya

$ ar rcs libutil.a a.o b.o      # b.o defines log_init()
$ gcc main.o -lutil             # main never references log_init

Agar main.o kabhi b.o ke kisi symbol ko reference nahi karta, toh b.o link nahi hota (archives sirf woh members pull karte hain jo current undefined ko satisfy karein). b.o ke andar ka __attribute__((constructor)) silently run nahi karega! Fix: b.o ko directly link karo, ya inclusion force karo: -Wl,--whole-archive -lutil -Wl,--no-whole-archive. Yeh step kyun? --whole-archive "only on demand" rule ko override karta hai aur har member ko include karta hai.

Common mistakes ko steel-man karna

Recall Feynman: ek 12-saal ke bacche ko explain karo

Socho tum ek hallway mein lockers ke aage se ek baar guzar ke school bag pack kar rahe ho, kabhi peeche nahi mudna. Jab bhi koi note milta hai "mujhe ek red pen chahiye," tum agle locker se red pen uthate ho jisme woh ho. Lekin agar tum pens se bhare locker tak pahunch jaate ho pehle koi maange bina, tum seedha aage nikal jaate ho — tum sirf wahi uthate ho jo kisi ne pehle hi maanga ho. Toh agar jis bacche ko pen chahiye woh pen locker se aage hallway mein hai, use kabhi pen nahi milega. Lesson: maangne waale ko dene waale se pehle rakho.

Flashcards

Traditional Unix linker apni command line kis direction mein scan karta hai, aur kitni baar?

Left to right, ek single pass (objects/archives ek baar process hote hain; sirf --start-group ya repeat karna re-scan force karta hai).

Linker resolution ke dauran teen sets kya maintain karta hai?

E

(executable mein jaane wale objects),

U

(abhi ke undefined symbols),

D

(pehle se define kiye gaye symbols).

Static archive .a ka koi member link mein kab pull hota hai?

Sirf agar, linker ke archive tak pahunchne ke waqt, woh member

U

mein currently koi symbol define karta ho (undefined).

gcc -lm main.o fail kyun hota hai jabke gcc main.o -lm kaam karta hai?

Pehle -lm par,

U

khaali hai isliye sqrt.o pull nahi hota; main.o baad mein sqrt undefined banata hai lekin libm pehle hi pass ho chuka hai. Objects libraries se pehle aane chahiye jo unhe use karte hain.

Link line par libraries rakhne ka general rule?

Objects pehle, phir libraries; har library us har object/library ke baad jo usse depend karta hai (user provider se pehle).

Do static libraries ke beech circular dependency kaise resolve karte hain?

Ek library repeat karo (-lfoo -lbar -lfoo) ya inhe -Wl,--start-group ... -Wl,--end-group mein wrap karo taaki repeated scanning force ho.

--whole-archive kya karta hai aur iske zaroorat kyun hai?

Archive ke har member ko link hone ke liye force karta hai, chahe reference ho ya na ho — tab zaroori hota hai jab kisi member ke side effects hote hain (jaise ek constructor) lekin koi referenced symbol nahi hota.

Multiple definitions ke liye strong vs weak symbol rule?

Ek strong + kai weak → strong definition silently choose hoti hai; do strong → multiple-definition error. (-fno-common tentative globals ko errors banata hai.)

Connections

Static vs Shared Libraries
The Linker (ld) and Linking Phases
Object File Format (ELF) and Symbol Tables
Name Mangling in C++
Build Systems & Toolchain
Library Constructors and __attribute__((constructor))