On Mon, 1 Aug 2022 11:32:20 +0200
"Roberto E. Vargas Caballero" <k0ga_AT_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
Received on Wed Aug 03 2022 - 15:21:30 CEST