Subject: Re: ar
To: None <tv@pobox.com>
From: ITOH Yasufumi <itohy@netbsd.org>
List: tech-toolchain
Date: 12/13/1999 17:39:30
[ about ar and symbol table ]

src/gnu/dist/bfd/archive.c:
>  Symbol table (must be first):
>  "__.SYMDEF       " - Symbol table, Berkeley style, produced by ranlib.
>  "/               " - Symbol table, system 5 style.

The difference is from the change of the encoding of filename.

src/gnu/dist/bfd/archive.c:
>  Regular file members with short names:
>  "filename.o/     " - Regular file, System 5 style (embedded spaces ok).
>  "filename.o      " - Regular file, Berkeley style (no embedded spaces).

Then, we have some alternatives.

ar format:
 1. ar produces Berkeley file format
 2. ar produces SysV ("/" at the end of file names) file format

ar symbol table:
 a. ar doesn't produce symbol table
 b. ar produces "/" table
 c. ar produces "__.SYMDEF" table

ranlib:
 A. ranlib produces "__.SYMDEF" table
 B. ranlib produces "/" table
 C. ranlib produces "__.SYMDEF" table unless it has "/" table
 D. ranlib produces "/" table unless it has "__.SYMDEF" table
 E. ranlib doesn't exist

The orignal Berkeley systems are 1-a-A.
The SysV systems are 2-b-E.
Currently we have 1-b-C toolchain.

Apparently, 1-b-* and 2-c-* are inconsistent in the sense
of namespace of filename of the archived files.

My proposal was 1-a-A or 1-a-C, which is compatible to Berkeley's.

In article <Pine.NEB.4.20.9912100954350.8284-100000@server.int.duh.org>
tv@pobox.com writes:

> The ELF toolchains on SYSV-derived systems (where ELF came from) have no
> ranlib(1).  The ar(1) program implicitly does the function of ranlib(1)
> automatically.
> 
> The correct thing to do is fix the ranlib handling (or see if a fix already
> exists)--after all, binutils is used by much more than NetBSD on ELF.

Then, is your proposal is 2-b-E, just like as SysV systems?

Changing archive format will make compatibility problems...
--
ITOH, Yasufumi <itohy@netbsd.org>