🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

4 total messages Started by Sam Kendall Tue, 19 Nov 1985 04:54
lorder(1) bug + fix (all UNIX systems)
#1
Author: Sam Kendall
Date: Tue, 19 Nov 1985 04:54
153 lines
4393 bytes
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
Re: lorder(1) bug + fix (all UNIX systems)
#2
Author: Henry Spencer
Date: Sun, 24 Nov 1985 02:48
12 lines
1193 bytes
>        ...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
Re: lorder(1) bug + fix (all UNIX syste
#3
Author: hamilton
Date: Mon, 25 Nov 1985 23:28
21 lines
1751 bytes
>>        ...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
Re: lorder(1) bug + fix (all UNIX system
#6
Author: rs
Date: Tue, 03 Dec 1985 16:47
12 lines
1144 bytes
/* 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
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads