kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (03/09/90)
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? Thanks. kaleb@mars.jpl.nasa.gov Jet Propeller Labs Kaleb Keithley spelling and grammar flames > /dev/null
hvr@kimba.Sun.COM (Heather Rose) (03/11/90)
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
guy@auspex.auspex.com (Guy Harris) (03/13/90)
>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.
david@eng.sun.com ("Life is like a pan full of boiled rats' heads.") (03/13/90)
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
guy@auspex.auspex.com (Guy Harris) (03/14/90)
>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). Yup, I'd forgotten that little Tale of Terror from 4.0 development days. If you have to do something like if (foo->bar->bletch == mem_rop) { /* * Do special memory pixrect stuff */ } else { /* * Do other pixrect stuff */ } this comes into play (i.e., it's not *any* reference by name that causes problems, it's references that actually care about the address of the function as something other than the target of a jump).