Reputation: 429
My C textbook creates an archive using the -s command line option which adds an index to the following archive file.
ar -rcs libfile.a file1.o file2.o
However, I don't understand what an index is or it's purpose?
Upvotes: 4
Views: 1332
Reputation: 754760
Converting comments into an answer.
There's a long, complicated history tied up in part with the ranlib
program. Basically, for the linker to be able to scan a library efficiently, some program — either ar
itself or ranlib
— adds a special 'index' file which identifies the symbols defined in the library and the object file within the archive that defines each of those symbols. Many versions of ar
add that automatically if any of the saved files is an object file. Some, it seems, require prodding with the -s
option. Others don't add the index file at all and rely on ranlib
to do the job.
The ar
on macOS documents:
-s
— Write an object-file index into the archive, or update an existing one, even if no other change is made to the archive. You may use this modifier flag either with any operation, or alone. Runningar s
on an archive is equivalent to runningranlib
on it.
I've not needed to use this option explicitly on macOS for a long time (nor have I run ranlib
) — I think things changed sometime in the middle of the first decade of the millennium.
Don't object files already come with symbol tables? Wouldn't it seem redundant to add another symbol table to the start of the archive file?
Each object file contains information about what's in that one object file (and information about referenced objects as well as defined ones); the archive index contains much simpler information about which of the many object files in the archive defines each symbol, so that the linker doesn't have to scan each object file in the archive separately.
So, would it be correct to say that the index at the start of the archive is just a giant symbol table which replaces the individual symbol tables in each object file so the linker has an easier job?
Not replaces — augments. It allows the linker to identify which object file(s) to pull into the linked executable. The linker then processes the object files just as it does any other object file, checking for definitions and references, marking newly defined references as satisfied and identifying previously unused references that are not yet defined. But the linker doesn't have to read every file in the archive to work out which symbols are defined by the file — it knows from the index file which ones are defined.
To clarify the index allows the linker to find the specific object file which defines a symbol rather than having to scan every object file to resolve a symbol?
Yes, that’s right.
Upvotes: 5