🚀 go-pugleaf

In article <3019@jato.Jpl.Nasa.Gov> kaleb@mars.jpl.nasa.gov (Kaleb Keithley) writes:
>We have ICS's Motif binaries, and would like to convert the toolkit library
>to a shared library.
>
>Does anyone have any tips, tricks, or caveats on how I might go about doing
>this?

Well, from my rather limited experience with shared libraries in SunOS,
the method differs with the implementation used by your operating system.  

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*.
Without this, the references in the client code to this information will not 
be able to be relocated at ld time -- and the relocation must be done at 
execution time.  This adds to the memory load of the system. (thanks Rob G.)

For example, the version of libpixrect in SunOS 4.0 did not include the
texture data structures in the .sa part.  As a consequence, when a client
program used these structures by name, it got incorrect data.  The affects were
anything from wrong looking lines to core dump when drawing.

The larger your .sa, the less sharing you get.  Anyway, the SunOS documentation
set includes more information on this.  It is not a trivial task to create a
proper shared library.  One needs to know the library interface and whether
global data is a part of it.  The XView library separates out this data into
files named <foo>data.c.

Also, if you use something like xstr to reduce the library size, there are
other considerations as well.  xstr should not be run on the global data
modules.

For an example, you may want to look at the XView source code with patch2
applied.  This shows one example of a shared library for SunOS.

__________________________________________________________________
Heather Rose
Window Systems Group                      internet:  hrose@sun.com
Sun Microsystems, Inc.                        uucp:  ...!sun!hrose