[net.bugs.v7] lorder

sam@delftcc.UUCP (Sam Kendall) (11/19/85)

Index:	usr.bin/lorder.sh 4.2BSD +FIX

Description:
        Lorder(1) on (almost) all UNIX systems may produce incorrect
        ordering for object files containing uninitialized external
        (common) symbols.  Lorder tries to classify all symbols as
        "defs" or "refs", but a common symbol can be either, depending
        on the other instances of the symbol in other object files.

        This is most important on V7 systems, where this bug can lead
        (and has led, at this site) to undefined symbol errors from the
        loader, due to incorrect archive ordering.  This can also happen
        on 4.2BSD systems if ranlib(1) is not used.

        Lorder is less widely used on 4.2BSD and System 5.2 systems, but
        its use is necessary to ensure source portability to V7 and
        other systems (MS-DOS?) which lack System V's archive table of
        contents or 4.2BSD's ranlib.  That's probably why it is still
	around.

        Note: this bug will not occur on System 5.0 and other systems
        whose loaders do not support common storage.

Repeat-By:
	Write the following 3 files:
		main.c:		main(){
					f();
				}
		extern.c:	f(){
					extern int common;
					common = 5;
				}
		common.c:	int common;

	Compile them like this:
		cc -c main.c common.c extern.c
		ar cr lib.a `lorder common.o extern.o | tsort`
		cc main.o lib.a

        Ld will give a message about "_common" (or "common") undefined,
        because common.o was incorrectly placed before extern.o in the
        archive.

Fix:
        Lorder is almost identical on all UNIX systems.  The fix here is
        for the V7/4.2BSD version.  For System V: (1) don't change the
        options to nm; (2) add to the sed script to make the added part
        parallel to the other 2 parts, rather than exactly like what I
        have below.

	The temporary files should be put in /tmp--otherwise lorder will
	fail if the current directory is not writable--but I haven't
	bothered.

*** /usr/bin/lorder	Tue Sep 27 12:54:25 1983
--- /usr/lbin/lorder	Tue Aug 13 10:57:33 1985
***************
*** 1,4
  trap "rm -f $$sym?ef; exit" 0 1 2 13 15
  case $# in
  0)	echo usage: lorder file ...
  	exit ;;

--- 1,10 -----
  trap "rm -f $$sym?ef; exit" 0 1 2 13 15
+ 
+ # modified 8/13/85 by sam@delftcc.UUCP.  
+ # (1)	3rd tmp file $$symcef added for common blocks, which can sometimes
+ #	be refs, sometimes defs.
+ # (2)	-p option speeds up nm.
+ 
  case $# in
  0)	echo usage: lorder file ...
  	exit ;;
***************
*** 6,12
  	*.o)	set $1 $1
  	esac
  esac
! nm -g $* | sed '
  	/^$/d
  	/:$/{
  		/\.o:/!d

--- 12,18 -----
  	*.o)	set $1 $1
  	esac
  esac
! nm -pg $* | sed '
  	/^$/d
  	/:$/{
  		/\.o:/!d
***************
*** 23,28
  		w '$$symdef'
  		d
  	}
  	s/.* //
  	G
  	s/\n/ /

--- 29,41 -----
  		w '$$symdef'
  		d
  	}
+ 	/C /{
+ 		s/.* //
+ 		G
+ 		s/\n/ /
+ 		w '$$symcef'
+ 		d
+ 	}
  	s/.* //
  	G
  	s/\n/ /
***************
*** 30,34
  	d
  '
  sort $$symdef -o $$symdef
  sort $$symref -o $$symref
  join $$symref $$symdef | sed 's/[^ ]* *//'

--- 43,49 -----
  	d
  '
  sort $$symdef -o $$symdef
+ sort $$symcef -o $$symcef
  sort $$symref -o $$symref
  {
  	join $$symref $$symdef
***************
*** 31,34
  '
  sort $$symdef -o $$symdef
  sort $$symref -o $$symref
! join $$symref $$symdef | sed 's/[^ ]* *//'

--- 45,52 -----
  sort $$symdef -o $$symdef
  sort $$symcef -o $$symcef
  sort $$symref -o $$symref
! {
! 	join $$symref $$symdef
! 	join $$symref $$symcef
! 	join $$symcef $$symdef
! } | sed 's/[^ ]* *//'

----
Sam Kendall
Delft Consulting Corp.
(212) 243-8700
{allegra, seismo!cmcl2, ihnp4}!delftcc!sam

henry@utzoo.UUCP (Henry Spencer) (11/24/85)

>        ...This can also happen on 4.2BSD systems if ranlib(1) is not used.
>        Lorder is less widely used on 4.2BSD and System 5.2 systems, but
>        its use is necessary to ensure source portability to V7 and
>        other systems (MS-DOS?) which lack System V's archive table of
>        contents or 4.2BSD's ranlib....

Once again the Berkloids get credit for something they had nothing to do
with...  Ranlib came from Bell Labs and was included in V7, although it seems
to have been a late addition and the as-distributed V7 libraries don't use it.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

hamilton@uiucuxc.CSO.UIUC.EDU (11/26/85)

>>        ...This can also happen on 4.2BSD systems if ranlib(1) is not used.
>>        Lorder is less widely used on 4.2BSD and System 5.2 systems, but
>>        its use is necessary to ensure source portability to V7 and
>>        other systems (MS-DOS?) which lack System V's archive table of
>>        contents or 4.2BSD's ranlib....
>Once again the Berkloids get credit for something they had nothing to do
>with...  Ranlib came from Bell Labs and was included in V7, although it seems
>to have been a late addition and the as-distributed V7 libraries don't use it.

so who are we supposed to give credit to?  to Bell Labs for distributing a
useless ranlib?  or to berkeley whose libraries can be usefully ranlib'ed?
i think berkeley deserves a teeny bit more credit than "nothing to do with".

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton@uiucuxc.cso.uiuc.edu
CSNET:	hamilton%uiucuxc@uiuc.csnet
USMail:	Box 476, Urbana, IL 61801
Phone:	(217)333-8703

henry@utzoo.UUCP (Henry Spencer) (11/29/85)

> >Once again the Berkloids get credit for something they had nothing to do
> >with...  Ranlib came from Bell Labs and was included in V7, although it seems
> >to have been a late addition and the as-distributed V7 libraries don't use it.
> 
> so who are we supposed to give credit to?  to Bell Labs for distributing a
> useless ranlib?  or to berkeley whose libraries can be usefully ranlib'ed?

Whatever gave you the idea that Bell Labs ranlib didn't work, or wasn't
useful?  Neither is true.  It wasn't used on the libraries on the V7 tape,
but that does not mean it can't be.  Bell Labs is not in the business of
preparing polished software distributions (neither is Berkeley!); the
libraries weren't ranlibbed simply because nobody had got around to doing it.

> i think berkeley deserves a teeny bit more credit than "nothing to do with".

Why?  Ranlib was written by Steve Bourne, at Bell Labs.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

henry@utzoo.UUCP (Henry Spencer) (12/01/85)

> ... Ranlib was written by Steve Bourne, at Bell Labs.

Argh.  Mea culpa, mea maxima culpa.  I should have checked my information out
more thoroughly.  It wasn't Steve Bourne, but Peter Weinberger.  My apologies
to everyone, and Peter in particular; I will be more careful in future.

Note that it was still Bell, not Berkeley.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

rs@mirror.UUCP (12/03/85)

/* Written  5:04 pm  Nov 28, 1985 by henry@utzoo in mirror:net.bugs.v7 */
> preparing polished software distributions (neither is Berkeley!); the
> libraries weren't ranlibbed simply because nobody had got around to doing it.

I thought that, if the library were ordered maximally with lorder/tsort/etc,
ranlib actually slowed the process down a great deal!

--
Rich $alz	{mit-eddie, ihnp4!inmet, wjh12, cca, datacube}!mirror!rs
Mirror Systems	2067 Massachusetts Avenue  Cambridge, MA, 02140
Telephone:	6,176,610,777