Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!apple!sun-barr!newstop!sun!eng.sun.com
From: david@eng.sun.com ("Life is like a pan full of boiled rats' heads.")
Newsgroups: comp.windows.x
Subject: Re: Motif shared library?
Message-ID: <132857@sun.Eng.Sun.COM>
Date: 13 Mar 90 05:44:36 GMT
References: <3019@jato.Jpl.Nasa.Gov> <132807@sun.Eng.Sun.COM> <3024@auspex.auspex.com>
Sender: david@sun.Eng.Sun.COM
Lines: 20

In article <3024@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>In terms of how to do it on SunOS 4.0.x, you create two parts to a shared 
>>library--.so and .sa.  The .so is the entire shared library.  The .sa part
>>contains the information that a client of the library references *by name*.
>
>Err, it contains *data* that the client may reference by name - not
>code, even if it is referred to by name.  If it contained code, said
>code wouldn't be shared. 

The .sa file may have to contain code, if the address of a function is
referenced by both library code and library client code (e.g. mem_rop in
the pixrect library).

You are correct that said code is not shared -- if the function in
question is of any significant size it is best to put just a stub in the
.sa file, with the real code in the .so file.  Of course this incurs
additional run-time overhead in order to increase sharing.

-- 
David DiGiacomo, Sun Microsystems, Mt. View, CA  sun!david david@eng.sun.com