I know that object files(.o) are always relocatable,
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
.a file is just an archive of other files. Typically those are
.o files, to which you already know the answer. They don't have to be though - they don't have to be object code at all in fact - they can literally be any files you like.
.so file has to be relocatable to work as it has to be able to be loaded at different addresses in different processes depending on what address is available at runtime.
Let us start with what is the established definition of relocatable. A piece of code is relocatable, if it can be placed anywhere in memory without change and execute properly. So neither .o and .a files can be relocatable, because they are not pieces of code (!). A .o files contains a piece of code with accompagnying information and a .a files is a collection of whatever files, possibly .o.
Then, is the code contained in a .o relocatable? No, not in general, because it has to be souped up by a linker to fill in addresses using information that is supplied with the .o file. E.g. a sine is calculated using a polynomial evaluator that is in some other library only the linker knows about. So the call address of the polynomial evaluator must still be filled in; in other words, the code cannot be executed as such.
At last, the code in a .so file is relocatable, because this code is shared and can be executed by several processes at once. It would be inconvenient if all those processes had to place the code at the one address where it executes properly.
It might be a little late, but let me try:
Bonus: an executable doesn't have to be 'pic', but if it is, ASLR can be used when running it: https://en.wikipedia.org/wiki/Address_space_layout_randomization