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,