Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (MU) 9/23/84; site munnari.OZ
Path: utzoo!linus!decvax!mulga!munnari!kre
From: kre@munnari.OZ (Robert Elz)
Newsgroups: net.bugs
Subject: Re: Unusual failure of ranlib
Message-ID: <596@munnari.OZ>
Date: Sat, 24-Nov-84 13:26:03 EST
Article-I.D.: munnari.596
Posted: Sat Nov 24 13:26:03 1984
Date-Received: Sat, 24-Nov-84 08:36:28 EST
References: <152@psivax.UUCP>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 44

In article <152@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes:
| 
| 	We have run into an unusual, and frustrating error in ranlib.
| We are using it in conjunction with make and ar to maintain a series
| of archives being shared by several users.  Periodically it will choke
| on an existing archive with the following message:
| 
| ranlib: arname(__.SYMDEF): old format .o file
| 
| Once it has done so it will continue to choke on that archive.
| Deleting __.SYMDEF from the archive and re-making it works, but ranlib
| procedes to choke again next time it is used.  Also following this
| the program nm fails with a similar error message. I have been unable
| to determine the conditions under which this behavior is initiated.
| 
| P.S. One archive which exhibited this behavior for awhile has cleared up.?

The problem occurs when the number of entry points in the archive
just happens to make the first word of the __.SYMDEF file be 0408.
(This is calculated as (num of entry points) * sizeof(struct ranlib)).

Unfortunately, there is no simple fix, without changing ranlib and ld
and breaking all existing ranlib'd libraries, and we know how much people
complain whenever something has to change to fix a bug :-)

The "work around it" kludge is simply to add a new entry point
to the archive (most easily done by adding a dummy file, that
is never going to be used, as ...

	/* ranlib_bug.c */
	_d_u_m_m_y_() {}

which, while ugly, will change the number of entry points).  Worst
of this "solution" is that should another entry point be deleted,
then the problem will simply occur again (solution now is to delete
the dummy entry ....).

A better fix would be to simply to add a real magic number at the
start of __.SYMDEF files (then ld could check that, and not simply
rely on the name __.SYMDEF in the archive), but I will leave that
for Berkeley to do sometime, so they will have to suffer all the
abuse from people who relied on the old behaviour.  They are used to it!

Robert Elz					decvax!mulga!kre