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

From: Roberto E. Vargas Caballero <k0ga_AT_shike2.com>
Date: Mon, 1 Aug 2022 11:32:20 +0200

Hi,

On Sun, Jul 31, 2022 at 01:00:23AM +0200, Laslo Hunhold wrote:
> I must admit that I only copied the ar-ranlib-invocation likewise from
> what I found on the internet for my libraries, so even though I don't
> think it makes any difference (i.e. increases portability apart from
> standards-legalese), it helps to make ranlib more and more superfluous
> and promote the best practice, which is why I pushed your described
> change for libgrapheme[0].

There is a big important reason why scc ar does not generates a link table,
because then ar can handle any type of files, because ar is just an archiver.
Making ar(1) to generate symbol tables means that ar has to do detection
of type files, meaning that it has to support all the possible binary formats.

At this moment scc ar is able to generate libraries for any system, without
a symbol table yes, but thay are going to work. In this point we have several
standard to consider. POSIX does not enter in binary formats, it is out of
the scope of the standard, and htis is why as(1) and ld(1) are out of the
specification, and it does not mean that you should not use them, it is just
that they cannot be standarized. ELF specification implies that ar should
generate a symbol table, but not a.out ar. If you want to be sure that you
have a symbl table then you *need* ranlib, otherwise it depends of the system
where you execute.

Again, ranlib(1) is out of POSIX because it cannot standarize this kind of
topics, not because it is legacy. In fact, MacOS requires use of ranlib (or
at least it needed the last time that I tested scc in MacOS). You cannot
know what system require it or not, so the only safe option is to use ranlib.

Regards,
Received on Mon Aug 01 2022 - 11:32:20 CEST