On Wed, 13 May 1998 16:42:50 -0700  Jason Thorpe wrote:

> On Wed, 13 May 1998 16:52:13 -0700 (PDT) 
>  Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
> 
>  > So, how about we update the intree source for gcc and egcs for all ELF
>  > ports while we're at it (and send patches back to FSF/egcs?)
> 
> Not gcc - we're going for egcs and binutils.  "We're working on it."


Looking at this more - there's actually in "invisible" record which
appears to be the symbol table at the top of the archive.  This doesn't
show up on the NetBSD/pmax ar, but does on both the NetBSD/i386 and
Ultrix ar:

	netbsd/pmax: ar tv libxx.a
		rw-rw-r-- 7006/25   1425 May 14 10:22 1998 b.o
		rw-rw-r-- 7006/25   1425 May 14 10:22 1998 a.o
	netbsd/i386: ar tv libxx.a
		---------       0/0            50 May 13 17:22 1998 /
		rw-rw-r--    7006/25         1425 May 13 17:22 1998 b.o/
		rw-rw-r--    7006/25         1425 May 13 17:22 1998 a.o/
	ultrix: ar tv libxx.a
		---------    0/0        50 May 14 10:22 1998 
		rw-rw-r-- 7006/25     1425 May 14 10:22 1998 b.o
		rw-rw-r-- 7006/25     1425 May 14 10:22 1998 a.o

The contents of the "empty" record contains the symbol names of a.o and
b.o.  Further more, running ranlib updates the timestamp on the emtry
record:

	netbsd/pmax: ranlib libxx.a
	netbsd/pmax: ar tv libxx.a
		rw-rw-r-- 7006/25   1425 May 14 10:22 1998 b.o
		rw-rw-r-- 7006/25   1425 May 14 10:22 1998 a.o
	netbsd/i386: ar tv libxx.a
		---------       0/0            50 May 13 17:23 1998 /
		rw-rw-r--    7006/25         1425 May 13 17:22 1998 b.o/
		rw-rw-r--    7006/25         1425 May 13 17:22 1998 a.o/
	ultrix: ar tv libxx.a
		---------    0/0        50 May 14 10:23 1998 
		rw-rw-r-- 7006/25     1425 May 14 10:22 1998 b.o
		rw-rw-r-- 7006/25     1425 May 14 10:22 1998 a.o

Also, the "empty" record only gets created of the files being added
to the archive are valid object files - the names of the files are
unimportant.  It's also worth noting that with binutils 2.8.1, ar also
creates the symbol table automatically - there's no need to run ranlib.
They're pretty much the same program.

If I create libxx.a under Ultrix with only a.o and b.o in it, and then
link against libxx.a under NetBSD/pmax, I get:

	vlad:~/foof 52> cc -c main.c
	vlad:~/foof 53> cc -o main main.o libxx.a 
	libxx.a: could not read symbols: Archive has no index; run ranlib to add one
	vlad:~/foof 54> ranlib libxx.a
	vlad:~/foof 55> cc -o main main.o libxx.a
	vlad:~/foof 56> ./main
	0
	vlad:~/foof 57>

A little more digging around (this time in /usr/src/usr.bin/make) shows
the following comments:

 *-----------------------------------------------------------------------
 * ArchSVR4Entry --
 *      Parse an SVR4 style entry that begins with a slash.
 *      If it is "//", then load the table of filenames
 *      If it is "/<offset>", then try to substitute the long file name
 *      from offset of a table previously read.
 *-----------------------------------------------------------------------

If I rebuild make with -D__ELF__, everything works fine!

So, short term can we just add __ELF__ to the current in-tree gcc mips
CPP_PREDEFINES, or is egcs that close on mips that it doesn't matter?  I
would also like to get this in the 1.3 branch, so that 1.3.3 (if there
is one) will get the fix.

A longer term question is whether or not we need to keep ranlib.  The
ELF platforms current use the binutils toolchain, whilst the a.out
platforms use the BSD ar and ranlib.  If all platforms move to ELF, do
we keep and modify our current ar/ranlib or move to binutils?

Much rambling, but I've learnt a little bit more about the ways of the
world today...

Simon.
--
For reference:

  a.c:
	int this_is_function_a()
	{
		return(0);
	}
  b.c:
	int this_is_function_b()
	{
		return(0);
	}
  main.c:
	main()
	{
		printf("%d\n", this_is_function_a());
	}

  the first couple of lines of libxx.a after being ranlib'd:

	file: libxx.a
	00000000 | 213c 6172  6368 3e0a  2f20 2020  2020 2020 | !<arch>./       
	00000010 | 2020 2020  2020 2020  3839 3531  3036 3231 |         89510621
	00000020 | 3720 2020  3020 2020  2020 3020  2020 2020 | 7   0     0     
	00000030 | 3020 2020  2020 2020  3530 2020  2020 2020 | 0       50      
	00000040 | 2020 600a  0000 0002  0000 0076  0000 0644 |   `........v...D
	00000050 | 7468 6973  5f69 735f  6675 6e63  7469 6f6e | this_is_function
	00000060 | 5f61 0074  6869 735f  6973 5f66  756e 6374 | _a.this_is_funct
	00000070 | 696f 6e5f  6200 612e  6f2f 2020  2020 2020 | ion_b.a.o/      
	00000080 | 2020 2020  2020 3839  3531 3035  3334 3820 |       895105348 
	00000090 | 2020 3730  3036 2020  3235 2020  2020 3130 |   7006  25    10
	000000a0 | 3036 3634  2020 3134  3235 2020  2020 2020 | 0664  1425      
	000000b0 | 600a 7f45  4c46 0101  0100 0000  0000 0000 | `..ELF..........