On Mon, 1 Aug 2022 11:32:20 +0200 "Roberto E. Vargas Caballero" <k...@shike2.com> wrote:
Dear Roberto, > 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. now I understand, thanks for shedding light on this. This is a strong point and I understand the notion of the standards consortium. 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]: "When an archive consists entirely of valid object files, the implementation shall format the archive so that it is usable as a library for link editing (see c99 and fort77). When some of the archived files are not valid object files, the suitability of the archive for library use is undefined." And explicitly as an XSI-extension "When ar creates an archive, it creates administrative information indicating whether a symbol table is present in the archive. When there is at least one object file that ar recognizes as such in the archive, an archive symbol table shall be created in the archive and maintained by ar; it is used by the link editor to search the archive. Whenever the ar utility is used to create or update the contents of such an archive, the symbol table shall be rebuilt. The -s option shall force the symbol table to be rebuilt." What makes me wonder here is that you do in fact implement ranlib(1)[1] in scc. Could you please elaborate what difference it makes here and why you don't simply add the s-flag to ar(1)? Let me know if I'm wrong, but I don't see the difference between running ar(1) and then ranlib(1) to create a _foreign_ object-file-archive and doing so with the equivalent functionality implemented in ar(1). In both cases, you have to do file-detection, right? POSIX also gives you a lot of leeway, I think, with "When some of the archived files are not valid object files, the suitability of the archive for library use is undefined." you can pretty much skip creating the symbol table for foreign binaries. With best regards Laslo [0]:https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ar.html [1]:http://git.simple-cc.org/scc/file/src/cmd/ranlib%2Ec%2Ehtml