jf@ap.co.umist.ac.uk (John Forrest) (07/13/90)
If you don't use Apollo/Domain computers you can stop reading here. We put this message up a while back, but got no real reply. Essentially has anyone managed to get the MIT R4 distribution to work on OS10 Apollo's using global inlibs? We do it with local inlibs fairly successfully - the essential changes to the distribution are related to some extra shell scripts in utils which are used instead of cc and ar (they call cc and ar, but not always in a simple manner). Various lines for load options are also changed, but not by much. The current setup inlibs all library modules that appear in files called .shared in the appopriate source directories. This allows us some form of control. We currently inlib Xlib, Xt, Xaw, Xmu and the extensions library [ We run an "Athena" environment without motif or XView, but the same principles apply ]. The problem with this is, however, that the initial data portion of these libraries appears in virtually every process (X or not), and add's up to ~ 100K of redundant data per process. Compared to the plus side that simple X programs such as xload take only 5K of code space, this seems worth it. However, a better approach, if possible, would be to use global inlibs - where the initial tables could be made read-only, and thus the total memory usage would be a lot less. However, my experience with global inlibs is limited - I have got one library to work (a replacement for the supplied BIND resolve library), and found I could have only these sorts of variables: Read Only Initialised Static Variables RW Uninitialised Static Variables RW Uninitialised Global Variables RO Initialised Global Variables, but with the Data Replaced by 0's! Actually, I'm not completely sure about the latter. It might be I've done something wrong. The point is that I did manage to adapt the resolve library I ported, but only by making changes to the source - given the size of that library, too many really. Has anybody tried the equivalent with the X libraries? Even if all the ClassInitialize procedures are called at initial boot time, it ought to be possible? (shouldn't it?). I'd like to think someone has had some luck on this matter. John Forrest Dept of Computation UMIST Manchester UK.
runeaa@igf.unit.no (07/16/90)
I tried to mail to : jf%umaida%cns%mucs%ukc%mcsun%sunic%luth%eru@bloom-beacon.mit.edu (John Forrest) But it returned as "unknown host". I would like to know how you did compile X11.4 for Apollo shared librarys. I myself have X11.4 going on a DN3500 with 155Mb disk and SR10.2, everything statically linked. Parts of the programs and libs are stored on a NFS server (sun) to conserve local disk space, but considering the (lack of) speed of the Apollo NFS implementation it is a pain to load 1Mb of program over the net. So I would like to rebuild the whole thing to use inlibs instead, but it is not obvious from the man pages and other documentation how to do this. If I could borrow some ideas from you, it would have been of great help. (How did you make xload work on an Apollo, I believed it was dependent on having /dev/kmem???) Rune Aasgaard, | Tel. +47-7-594573 Dept. of Geodesy and Photogrammetry, | Fax. +47-7-594621 Norw. Institute of Technology, | E-mail. runeaa@igf.unit.no N-7034 TRONDHEIM, NORWAY.
mengel@uniol.UUCP (A. Mengel) (07/17/90)
runeaa@igf.unit.no writes:
=>I tried to mail to :
=>jf%umaida%cns%mucs%ukc%mcsun%sunic%luth%eru@bloom-beacon.mit.edu
=>(John Forrest)
=>But it returned as "unknown host".
=>I would like to know how you did compile X11.4 for Apollo shared
=>librarys. I myself have X11.4 going on a DN3500 with 155Mb disk and
=>SR10.2, everything statically linked. Parts of the programs and libs
....
=>So I would like to rebuild the whole thing to use inlibs instead, but
=>it is not obvious from the man pages and other documentation how to do
=>this. If I could borrow some ideas from you, it would have been of
=>great help.
If you manage to get ANY suggestions, i would like you to send me a copy
or perhaps you could post a summary.
Bye,
Falcon
---------------------------------------------------------------------------
email: mengel@uniol.UUCP
bitnet: 169371@doluni1