Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!fwi.uva.nl!casper
From: casper@fwi.uva.nl (Casper H.S. Dik)
Newsgroups: comp.windows.x
Subject: Re: Making (Sun) Shared Libraries of Widgets
Message-ID: <1991May14.150515.6057@fwi.uva.nl>
Date: 14 May 91 15:05:15 GMT
Article-I.D.: fwi.1991May14.150515.6057
References: <1991May14.013454.8796@melba.bby.oz.au>
Sender: news@fwi.uva.nl
Organization: FWI, University of Amsterdam
Lines: 63
Nntp-Posting-Host: ophelia.fwi.uva.nl

gnb@bby.oz.au (Gregory N. Bond) writes:

>Does anyone have any experience or advice for creating shared library
>versions of widget sets?

>In particular, what files or chunks of file should be put in the .sa
>file?  I notice that none of the Xaw library is in an sa file, and
>only a few wrapper functions from Xt.

All data referenced by user programs should be exported.
If you don't do this, the resulting executable will need runtime
relocation. The library is still shared, the executable isn't.

The X consortium got that wrong.

>My reading of the SunOs manual suggests that as a minimum the class
>record should go there, and probably not much else.

Indeed, it should.

>Anyone illuminate the cost/benefit of splitting out the .sa stuff?

Putting data in .sa costs (cost only paid for executables which use data
from the .sa part):
	- larger executable.
	- data consists in both the shared library data part and
	  the data segment.
But you gain:
	- no runtime relocation of your binary:
		- binary is shared among processes
			(current cost: +/- 250k/xterm)
		- faster startup

Data put in .sa should also exist in .so part (if referenced by any
library function).

Some executable code can be put in the .sa part:

	- functions used in address comparisons
	- short, fast functions that are used a lot.
	(E.g. Sun's function implementation of the ctype macros)

Cost:
	More VM use.
Gain:
	Somewhat faster execution.

It should be clear that with Sun's implementation of shared libraries,
data is evil. X11R4 is a major offender in this respect.

VM consumption of an xterm process:
	statically linked:					X
	dynamically linked with properly constructed X lib	X+60k
	(large amounts of duplicated and unneeded data)
	dynamically linked with X libs as distributed:		X+250k
	(unshared executable)

Be aware that the .sa and .so must have exeactly the same revision number.
(E.g. both 1.4.1 and not 1.4.1 and 1.4)

--
JANET:						|	Casper H.S. Dik
      The English Network - Another Joke	|	casper@fwi.uva.nl