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>