mengel@uniol.UUCP (A. Mengel) (07/16/90)
Hi there I am looking for a way to compile the X11R4 distribution on our local Apollo-Domains using shared libraries. We are running SR10.1 an are soon upgrading to SR10.2. Has anyone already done this ?? Even the faintest hints will be welcome !! Bye, Falcon ------------------------------------------------------------------------------- Real Name: Andreas Mengel Bitnet: 169371@DOLUNI1 | UUCP: mengel@uniol.UUCP +-----------------------------------------------+ | To err is human | | But to mess up the whole thing, | | you really need a computer. | +-----------------------------------------------+
jf@ap.co.umist.ac.uk (John Forrest) (07/17/90)
In article <3087@uniol.UUCP>, mengel@uniol.UUCP (A. Mengel) writes: |> Hi there |> I am looking for a way to compile the X11R4 distribution on our local |> Apollo-Domains using shared libraries. |> We are running SR10.1 an are soon upgrading to SR10.2. |> Has anyone already done this ?? |> Even the faintest hints will be welcome !! |> On Apollo's "shared libraries" are called "inlib's". They come in several different flavours, but the main division is between: i) User inlibs, that are loaded into the address space of a run-time process via the inlib shell command or -inlib loader option. These are not particularly constrained in what you can do, but need different compile options and bind options. ii) Global inlibs, that are loaded at boot time and remain present throughout - the C library is an example of this. There are several constraints on what you can do, as after an initialisation phase, the system makes initialised data read-only. We have for several months run shared libraries based on method (i). There is nothing special about our distribution - the main changes are in the configuration and utility scripts. On building the libraries, the system checks to see if a file called .shared exists, and then to see if the module name is in that file. If so it compiles position independent (the main change), and when "ar" is called, the shared modules are put in a different library. We then run separately run a shell script that produces an inlib binary. We currently inlib the X and Xextensions libraries plus Xt, Xaw, and Xmu. This can be configured many ways, for example we could use the Xt library but not Xaw. If anyone wants a copy of our configuration stuff, they are welcome to it. The disadvantage of this method is that the various data and widget tables exist in every process running in an X session, whether they are X programs or not. This adds about 100K to every non-X process at run time. In my opinion this is worth it - for instance, the xclock binary is about 5K in size. However, it would be far better to use method (ii). However, in my opinion this would entail quite alot of change to the source files - this has at least been my experience with smaller global inlibs. Has anyone got further than this? I did put up a note myself the otherday, and the only reply I got suggested not. John Forrest Dept. of Computation UMIST UK.