Re: [dev] Replace ranlib(1) calls?

From: Tom Schwindl <>
Date: Sat, 23 Jul 2022 23:06:49 +0000


On Fri, Jul 22, 2022 at 05:26:52PM +0200, Roberto E. Vargas Caballero wrote:
> Hi,
> On Wed, Jul 20, 2022 at 12:23:01PM +0000, Tom Schwindl wrote:
> > ranlib(1) is, in fact, legacy. It was used to create symbol tables for archives
> > before ar(1) was able to do that by itself.
> > POSIX now specifies that ar(1) should create a symbol table by default, when
> > there is at least one recognized object file[1]. Additionally, the `s` option exists
> > which does exactly the same as ranlib(1)[2].
> Well, I disagree about ranlib to be obsolete. Ar is guaranteed to add an
> index in COFF and ELF systems, but not in a.out. I also know that 99.99%
> of the people will ignore such systems, but I personally care about them.
> Also, using ranlib doesn't harm so I personally don't see the advantage
> of removing it.

The main "problem" here is that ranlib(1) isn't a standardized tool, so there
is no guarantee on what its behaviour will be or whether it exists at all.
We assume it's there because it always has been or GNU and LLVM include it.
Relying on a utility which isn't defined by the specification we're using
doesn't make much sense to me. Especially if there *is* a *defined* flag which
does exactly the same thing as ranlib(1).

Bothering with systems which do not comply with "our" standards (by which I
mean POSIX) isn't worth it, unless there are concrete plans and good reasons
to support them (at least in my opinion).

> > ar rcs files...
> >
> > which not only makes the creation of static libraries more portable,
> > but also simpler.
> More portable? It is just the opposite, if you use ranlib you can support
> systems where ar doesn't create an index in the archive (for example if
> you use scc ar :P).

Again, you'd have to rely on a tool which isn't defined.
If a system says it's POSIX compliant, we can assume that the `-s' option
exists, but there is no standard which tells us whether ranlib(1) is available
or not.

We'd have to introduce exceptions and thus increase the complexity to support
edge cases because *they* do not comply to standards.

Best Regards,
Tom Schwindl
Received on Sun Jul 24 2022 - 01:06:49 CEST

This archive was generated by hypermail 2.3.0 : Sun Jul 24 2022 - 01:12:08 CEST