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

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Wed, 3 Aug 2022 16:38:14 +0200

On Wed, Aug 03, 2022 at 03:21:30PM +0200, Laslo Hunhold wrote:
> In a way, ar(1) is merely an archiver, but POSIX added a function that
> only applies to exclusively object-file-containing-archives, but stays
> away from specifics[0]:
> [...]

Yeah, POSIX be like that sometimes. You can have a perfectly simple
model of how a program is supposed to work, then POSIX comes along and
specifies one thing that fits in about as elegantly as a blue whale into
a stationary cupboard.

Another example would be the interactive mode for cp/mv/rm, applications
which have absolutely no business reading from terminal being forced to
do it. Or alternatively, you just sod this one aspect of it.

In this case, a simple archiver is supposed to do special things based
on the content of the files it is archiving. Or, alternatively, you say
no to that requirement, implement ar as a simple archiver, and ranlib as
a program that reads the archive, makes a symbol table, and adds it to
the archive. Possibly even by calling the ar program.

That design would afford some flexibility to the whole business: ar
doesn't need to know the object file format and ranlib doesn't need to
know the ar file format. Indeed ld could read the symbol table and
object files from the archive by calling ar, then nothing in the system
would depend on the precise format of the ar files. That would be
modular. I daresay, it would suck less than what POSIX wants you to do.

But those are just the 2 cents of a grumpy old millenial.

Ciao,
Markus
Received on Wed Aug 03 2022 - 16:38:14 CEST