Exercises — Symbol resolution — order matters

• Read main.o: put it in $E$. It defines main → $D=\{main\}$. It uses sqrt, not in $D$ → $U=\{sqrt\}$.
• Read libm.a: is any current $U$ symbol defined by a member? Yes, sqrt.o defines sqrt. Pull sqrt.o in. Now sqrt moves $U\to D$.
• Answer: $U=\varnothing$. Link succeeds. ✅

• Read libm.a first: at this moment $U=\varnothing$, so no member is pulled (nobody has asked for sqrt yet).
• Read main.o: it now needs sqrt → $U=\{sqrt\}$. But libm.a is already behind us; the linker never turns back.
• Answer: $U=\{sqrt\}$ → undefined reference to 'sqrt'. ❌

True. Position on the link line is part of the program's meaning for static archives, exactly because of the single-pass rule shown in Q1 vs Q2.

Corrected: gcc main.o -ljson. Reason: the object that asks for parse (main.o) must be scanned before the archive that provides it, so that parse is already in $U$ when libjson.a is reached.

gcc app.o -lgfx -lmem. Trace:

• app.o → $U=\{draw\}$.
• libgfx.a → member defining draw pulled in; it uses alloc_buf → $U=\{alloc\_buf\}$ (draw moved to $D$).
• libmem.a → defines alloc_buf → pulled in, $U=\varnothing$. ✅ Rule: user before provider, so -lgfx (the user of alloc_buf) comes before -lmem (the provider).

• main.o → $U=\{helper\}$.
• libutil.a: a.o defines helper → pull a.o. a.o references nothing new. b.o and c.o define symbols not in $U$ → skipped.
• Answer: exactly 1 member (a.o). b.o and c.o are dropped.

• main.o: $U=\{f\}$, $D=\{main\}$.
• liba.a: does any member define something in $U=\{f\}$? ga.o defines g, not f. Nothing pulled. $U=\{f\}$ still.
• x.o: defines f (moves to $D$), uses g → $U=\{g\}$.
• End: $U=\{g\}\ne \varnothing$ → fails undefined reference to 'g'. Why: liba.a was scanned before x.o asked for g, so ga.o was never pulled. Correct line: gcc main.o x.o liba.a.

1. Order: -lcrypto appears before the object that references crypto_hash, so at the archive $U$ didn't yet contain it.
2. Transitive gap: the member that defines crypto_hash itself references a further symbol not yet available, or the referencing object is itself in a later archive whose scan already completed — a circular/late dependency. (Fix via correct order or --start-group.) A third possibility for C++: name mangling mismatch, so the referenced name and the defined name differ.

It drops libssl.so. --as-needed keeps a shared library only if, when scanned, it satisfies a current undefined. -lssl is scanned before main.o, so $U=\varnothing$ → libssl.so is judged "not needed" and omitted → later main.o yields an undefined SSL_new. Even for shared libraries, user-before-provider holds. Fix: gcc -Wl,--as-needed main.o -lssl.

Naive gcc main.o -lfoo -lbar fails: pulling bar_do's member from libbar.a newly needs foo_help, but libfoo.a was already scanned → foo_help stays undefined. Fixes:

• Repeat: gcc main.o -lfoo -lbar -lfoo (second -lfoo satisfies foo_help).
• Group (preferred): gcc main.o -Wl,--start-group -lfoo -lbar -Wl,--end-group, which re-scans the enclosed archives until a full pass pulls nothing new — deliberately defeating the single-pass rule.

Two clean options:

• Link the member directly: gcc main.o boot.o -linit (an explicit object is always kept, so its constructor is present).
• Force whole archive locally: gcc main.o -Wl,--whole-archive -linit -Wl,--no-whole-archive -lother. --whole-archive includes every member of libinit.a regardless of $U$; --no-whole-archive immediately restores normal on-demand behaviour so -lother isn't bloated. See Library Constructors and __attribute__((constructor)).

Under legacy "common" rules: one strong + one tentative → the strong wins silently, so count == 5 and both files share that storage. Under -fno-common the tentative int count; becomes a real global definition → two strong definitions → multiple definition of 'count' error. Correct design: declare extern int count; in a header, define int count = 5; in exactly one .c.

• main.o: $U=\{f\}$.
• Group pass 1 over -lp -lq:
  • libp.a: p1.o defines f (in $U$) → pull. p1.o uses g → $U=\{g\}$. p2.o defines h ∉ $U$ → skip.
  • libq.a: q1.o defines g (in $U$) → pull. $U=\varnothing$. q2.o defines w ∉ $U$ → skip.
• Group pass 2: nothing new pulled → group ends.
• In $E$ (besides main.o): p1.o and q1.o. p2.o and q2.o are excluded (never in $U$). Answer count of extra members = 2.

gcc main.o -lp -lq. Trace:

• main.o → $U=\{f\}$.
• -lp: p1.o defines f, uses g → $U=\{g\}$.
• -lq: q1.o defines g → $U=\varnothing$. ✅ No cycle exists here (p depends on q, not vice versa), so plain user-before-provider order suffices — no --start-group needed. This is the mastery insight: reach for order first, groups only for true cycles.

Two compounding effects:

1. Order: -lfeatures is scanned before core.o asks for its symbols, so under --as-needed the linker sees $U$ has no libfeatures symbol yet and drops the .so from the recorded dependencies.
2. No link error because the plugin registers via a constructor side effect, not via a referenced symbol — nothing is "undefined," so the linker is silent; the failure only appears at runtime when the constructor never runs. Corrected: gcc plugin_registry.o core.o -Wl,--as-needed -lfeatures (all users before the provider). If registration still depends on an unreferenced member of a static archive, add -Wl,--whole-archive/--no-whole-archive around it.

Walk down a hallway of lockers once, never turning back, carrying a to-do list of things you still need. You only open a locker if it holds something already on your list. So put the kids who need things (your objects) at the front of the hallway and the supply lockers (libraries) at the back. If two supply lockers keep needing each other, you're allowed to walk that little stretch back and forth until nothing new is grabbed — that's --start-group.