%ESDSDF.DECnet@CRD.GE.COM (04/21/89)
Received: by DnaMail (v1.1); Thu Apr 20 16:25:05 1989 EDT Received: from george. by elroy.jetsons.com (3.2/SMI-3.2) id AA21072; Thu, 20 Apr 89 16:24:38 EDT Received: by george. (4.0/SMI-4.0) id AA04942; Thu, 20 Apr 89 16:28:21 EDT Date: Thu, 20 Apr 89 16:28:21 EDT From: dwight@george (Dwight H. Cooper) Message-Id: <8904202028.AA04942@george.> To: esdsdf!csbvax::mrgate::"smtp::expo.lcs.mit.edu::xpert" Subject: SunOS 4.0, X and shared libraries Has anyone attempted to make the X libraries into shared libraries under SunOS 4.0? One thing that needs to be done is to separate the definitions of any exported initialized data. These definitions go in separate files and are used to build the shared archive (.sa) files. The remaining code is used to build the shared object (.so) files. I briefly looked through the code for X lib and found XErrorList defined and initialized, but does it really need to be exported? Also, I am considering modifying gcc to help me find additional cases of exported initialized data definitions. (It seems easier than looking through all those files). Too bad Sun didn't supply such a tool :-) Is there anything else to watch out for? Is it worthwhile? Dwight Cooper GE Electronic Systems dcooper%esdsdf.decnet@crd.ge.com (609) 722-7235
dshr@SUN.COM (David Rosenthal) (04/21/89)
Dwight Cooper writes: > Has anyone attempted to make the X libraries into shared libraries under > SunOS 4.0? One thing that needs to be done is to separate the definitions > of any exported initialized data. These definitions go in separate files > and are used to build the shared archive (.sa) files. The remaining code > is used to build the shared object (.so) files. It is not actually necessary to build .sa files at all. Provided that you are not loading initialized read-only data into the text segment (in which case the dynamic linker might get confused and think the data was a procedure) the only thing that will happen if there is no .sa file is that the exported initialized data might get written to, in which case the page it is on will become private rather than shared. Inefficient, but still much more efficient than non-shared libraries. > I briefly looked through the code for X lib and found XErrorList defined > and initialized, but does it really need to be exported? Using nm -g | grep ' D ' on the library we find the following data definitions: _XErrorList _XErrorListSize _XrmQBoolean _XrmQColor _XrmQCursor _XrmQDims _XrmQDisplay _XrmQEfalse _XrmQEno _XrmQEoff _XrmQEon _XrmQEtrue _XrmQEyes _XrmQFile _XrmQFont _XrmQFontStruct _XrmQGeometry _XrmQInt _XrmQPixel _XrmQPixmap _XrmQPointer _XrmQString _XrmQWindow __XErrorFunction __XHeadOfDisplayList __XIOErrorFunction __Xdebug __qfree __reverse_byte __event_to_mask I believe that the __foo declarations are internal and thus not needed in the .sa file. Examining the file Quark.c we find that the _XrmQ* variables are not initialized and are thus not needed in the .sa file. This leaves: _XErrorList _XErrorListSize I believe that these should in fact be declared static in XErrDes.c - they are only used to provide default values for XGetErrorText() and should not be regarded as part of the library interface (they don't appear in the manual). So, it looks like there is no need for a .sa file at all. > Also, I am considering modifying gcc to help me find additional cases > of exported initialized data definitions. (It seems easier than looking > through all those files). Too bad Sun didn't supply such a tool :-) We did - its called nm. I think using it is easier than modifying gcc - in any case it is difficult to see how a compiler can decide if something forms part of the external interface to a library or is simply a bug :-) > Is there anything else to watch out for? Don't think so. > Is it worthwhile? Yup. David.