rmtodd@servalan.uucp (Richard Todd) (09/11/90)
For the past few days I've been trying to patch X11R4 to make the libraries shared under A/UX 2.0. I figure this ought to cut down on the memory wasted by having multiple copies of Xlib, Xt, etc. linked into each application. So far, I've been making some progress, armed with a set of diffs posted by a guy in Denmark that (among other things) make Xlib, etc. shared on Interactive Unix for the 386. This helps a lot, but not as much as you might think; evidently the shared library implementation is a good deal different between A/UX and SVR3, though the basic idea is the same (the SVR3 shared lib control file evidently supports a lot more handy directives, like #object noload...) So far, I've got what appears to be a working shared library version of libXext.a and a not-yet-working version of libXt.a (still tracking down a bug somewhere in there...). With libX11.a, however, there is a serious problem with mkshlib. For those of you who aren't too familiar with the innards of X11, the libX11.a library is made up of about 250(!) object files. Apparently this is too much for mkshlib. Mkshlib apparently (near as I can tell) creates the "target" library (the statically linked version of the library that is mapped in by clients), but the "host" library (the .a file that clients must be linked with) is missing a good many of the symbols from the shared library. From experiments with making little shared libaries, it looks like mkshlib puts a little "fake" .o file with some wierd name in the .a file for each .o file in the desired library; however, the libX11.a made by mkshlib seems to have only about 110 objects in it instead of the 250 one would expect. So, I have a couple of questions: 1. Is this behavior of mkshlib known? If so, is a fix likely in the near future? Is this another example of AT&T questionable design in making an internal array on one of their development tools a small fixed size, on the grounds that no-one would ever need, say, to make 250 .o files into a shared lib? I don't suppose there's an undocumented flag to boost the table sizes, like cc and the other tools have? 2. What exactly is mkshlib doing anyway to create the .a file, and is there any way it can be faked out? Looks like what it has to do is for each .o to create an assembly file defining all the addresses of the symbols defined in that .o file (defining each symbol to be at the address given to it when the "target" shared library is made) as well as some assembly code to do the initializations spec'd by the #init directives in the shared lib control file. Oh yeah, plus some magic to specify the pathname of the target shared library to the system (not sure how this works, except it seems to involve COFF segment called .lib). -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp