Please tell me what it does?
$ ar -r libsldap.a
"Teach a man to fish", I say:
> man ar
[...]
DESCRIPTION
The GNU ar program creates, modifies, and extracts from archives. An
archive is a single file holding a collection of other files in a
structure that makes it possible to retrieve the original individual
files (called members of the archive).
[...]
man is your friend.
ar -r libsldap.a list-of-object-files
This line creates Linux static library, which is actually archive file that contains one or more .o files. Compiler is used previously to create these .o files.
http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/static-libraries.html
Related
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?
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. Running ar s on an archive is equivalent to running ranlib 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.
I was shared a static library file('.a' file). When i opened it with 7z, it included two files, one without extension and one with .o extension. What are these files. Is the .o an object file here and which one of these file is actually linked during linking process.
More info about the .a file:
Lets name the file xyz.a:
When i un compress it or view it with 7z, i can see two files:
- xyz
- abc.o
The '.a' file can contain several '.o' files added by the ar utility. It can also contain an index mapping global symbols to the '.o' files that contain them. On some systems (mostly SysV or GNU based), ar's s option is used to update the index. On other systems (mostly BSD based), the index is updated by a separate ranlib utility.
To answer your questions, the '.o' files are the object (code) files that make up the library, the other file is the index, and some subset of the '.o' files will be linked by the linker, with the assistance of the index to determine which '.o' files are needed.
With the ld linker, the option -l foo would search for a dynamic library called libfoo.so or a static library called libfoo.a. Other ld options control whether it looks for a static or dynamic library and where to look for it.
I know that every header file, i.e. string.h, should have an object file in which
there is the proper implementation.
I also know that for GCC and glibc there is a libc.a or libc.so containing object files.
I tried to open libc.a to see if I could find, i.e., string.o but I didn't find it.
Why? Where can I find for every header the correspondent object file?
It may be implementation dependant. A single .h file may correspond to many .o or the opposite, you might have many .h for a single .o
For example, in my libc.a, I can see about one module per string function :
$ ar t libc.a | grep '^str' | sort
strcasecmp.o
strcasestr.o
strcat.o
strchr.o
strcmp.o
strcoll.o
strcpy.o
strcspn.o
strdup.o
strerror.o
strfmon.o
strftime.o
stringlist.o
strlcat.o
strlcpy.o
strlen.o
strmode.o
strncat.o
strncmp.o
strncpy.o
strndup.o
strnlen.o
strnstr.o
strpbrk.o
strptime.o
strrchr.o
strsep.o
strsignal.o
strspn.o
strstr.o
strtofflags.o
strtoimax.o
strtok.o
strtol.o
strtoll.o
strtonum.o
strtoq.o
strtoul.o
strtoull.o
strtoumax.o
strtouq.o
strxfrm.o
well, in my system, libc.so shows up in /lib
[sourav#braodsword temp]$ ls -l /lib/libc*
-rwxr-xr-x 1 root root 1611564 Mar 10 2010 /lib/libc-2.5.so
However, if you're looking for the source code, you'll not find that in .so file, anyway.
Again, don't expect, every header file declaration will have a defferent object file. They are taken together to form the shared library .so.
Is there any way to list the files used while creating .so file? nm cannot be useful and also `readelf' also. Does some table maintain information?
readelf -s libfoobar.so | grep FILE
you cannot list the object files used to create a shared object file, since that information is not stored by default in a shared object file. A shared library is fully linked so you cannot "unarchive" it. see reference, but you can list the functions contained using this command
nm -D /usr/lib/libopenal.so.1
I don't really understand what ar utility does on Unix systems.
I know it can be somehow used for creating c libraries, but all that man page tells me is that it is used to make archives from files, which sounds similar to, for example, tar....
The primary purpose is to take individual object files (*.o) and bundle them together into a static library file (*.a). The .a file contains an index that allows the linker to quickly locate symbols in the library.
Tar doesn't create files that linkers understand.
ar is a general purpose archiver, just like tar. It just "happens" to be used mostly for creating static library archives, one of its traditional uses, but you can still use it for general purpose archiving, though tar would probably be a better choice. ar is also used for Debian .deb packages.
Exactly, ar is an archiver. It simply takes a set of object files (*.o) and put them in an archive that you call a static library.
It takes code in the form of object files (.obj, .o, etc) and makes a static library (archive). The library can then be included when linking with ld to include the object code into your executable.
Take a look at the example usage in the Wikipedia article.
You might want to run man ar to get the full picture. Here's a copy of that on the web.
To quote:
The GNU ar program creates, modifies, and extracts from archives. An
archive is a single file holding a collection of other files in a
structure that makes it possible to retrieve the original individual
files (called members of the archive).
ar is considered a binary utility because archives of this sort are
most often used as libraries holding commonly needed subroutines.
ar is specifically for archives (or libraries) of object code; tar is for archives of arbitrary files. Anybody's guess why GNU refers to these as 'archives', in other environments this utility is called the 'librarian', and the resulting files just libraries.