Hello,
The linking process is intended to satisfy references to symbols which are not [yet] defined (or were defined earlier) in the code. Commonly, our code calls functions which are defined in one or more libraries. When the linker builds our code into a program, it discovers references from our code to these (externally defined) functions, and has to located the functions within the libraries, include them in the program under construction, and fix the references to them with their actual address.
The linker that comes with gcc/g++, ln, is (unfortunately) a 1-pass linker. This means that when ln scans a library for a currently-undefined function (let's call it a()), it doesn't keep track of all of the *other* functions it finds in the library. If, later, ln requires another function (call it b()), defined in the same library, but that library has already been scanned, ln will be unable to *remember* the location of this function, and will report an error, unless the library is scanned again. This problem can happen, for example, if a() comes before b() in the library, and b() calls a(). It can also happen across libraries. It is not unusual to see link-time commands which specify a library more than once, for just this problem.
1-pass linkers tend to be smaller (less complicated code, and less use of run-time memory) which, for ln, is likely historical; UNIX was typically run on small machines, and the 1-pass nature avoided keeping a large symbol table in memory, during ln's execution.
A 2-pass linker would avoid this kind of problem, by keeping the symbols defined in all of the libraries scanned around.
I suppose that the problem hasn't been big enough for anyone to decide to address. "If it ain't broke, don't fix it...?"
