Skip to content
Advertisement

linux: ranlib doesn’t seem to add any new information into an archive file?

The man page of ranlib says:

DESCRIPTION ranlib generates an index to the contents of an archive and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file.

Well, I tried to compile an archive file like below:

$ cat o.c
#include<stdio.h>
int f(){
  printf("hellon");
  return 2;
}

gcc -o o.o -c o.c
ar rc libmyobject.a o.o
cp libmyobject.a libmyobject.a.keep
ranlib libmyobject.a

I tried to compare the size of library file beforand after ranlib, I got:

-rw-rw-r-- 1 a a   1626 Oct  3 12:03 libmyobject.a.keep
-rw-rw-r-- 1 a a   1626 Oct  3 12:06 libmyobject.a

They’re the same size. This is out of my expectation. I expect that runlib will store some extra information into .a file. But actually, the file size is still the same.

So what job does ranlib actually do, how can I check what job has ranlib done? Thanks.

Advertisement

Answer

If binutils is compiled with --enable-deterministic-archives, then by default, multiple runs of ranlib on the same input sources will produce the same output file because it nulls out the timestamp, uid and gid values.

You can force it to be non-deterministic by passing the -U flag, which will cause the storing of the timestamp, uid and gid values, and because the timestamp will have changed the files will be different:

$ ranlib -U libmyobject.a
$ diff libm*
Binary files libmyobject.a and libmyobject.a.keep differ

however the file size will remain the same, though.

$ ls -l libm*
-rw-r--r-- 1 xx xx 1618 Oct  3 13:58 libmyobject.a
-rw-r--r-- 1 xx xx 1618 Oct  3 13:58 libmyobject.a.keep

Bear in mind that determinism in tools like this is actually quite desirable, as it allows for features like Reproducible Builds to work without having to add convolutions to the build process.

Advertisement