README SVR5 Ok floks, it really works !!! (PLEASE EVERYBODY WHO DEVELOPES X-APPLICATIONS SHOULD READ THIS !!!) 1) Building Applications There are now nice shared libs, but they also cause some BAD trouble. The basic problem is that the linker looks at the shared lib as one piece, and thinks that all symbols of this one have to be resolved at link-time. For examples libXaw includes a ClockWidget, which uses sin() and cos(). So every time you want to link an executable with that lib, you have also to specify -lm -- whether you'll need these functions or not -- in order to link the target properly. On the other hand is the dynamic linker so smart to detect the symbols that are needed. Therefor I added a -znodefs to the normal linkeroptions in order to allow such unused, unreloved symbols. To be sure that all symbols used for this application are really defined I suggest that in the prototyping phase the nonshared libraries should be used. Since these are identical to the shared one a unresolved symbol that is used would instantly be reported. But since this all is in my opinion to complex and to vulnarable for bugs the policy is now just to include all libs that are needed. This adds a overhead of about 3k to every application, but seems to be the only secure way. Thus there exist the following dependencies of libs, here mentioned as a set of rules: $(XLIB): -lsocket -lnls $(XTOOLLIB): $(XLIB) -lsocket -lnls $(XMU): $(XTOOLLIB) $(XLIB) -lsocket -lnls -lm $(XAW): $(XMU) $(XTOOLLIB) $(XLIB) -lsocket -lnls -lm 2) Library paths Every library (shared and nonshared) is now located in two places: /usr/lib Convenient for normal build $(X386HOME)/lib Normally /usr/lib/X11/X386/lib In the latter directory there are also the 'runtime shared libs'. These are the normal shared libs but with a different suffix. For example if there is a /usr/lib/libX11.so there is a companion /usr/lib/X11/X386/lib/libX11.so.1. Why so complicated ?? In the future (X11R5 may come soon ... ) there might be a incompatible version of the shared lib. Thus there is a version number maintaioned within the shared lib. Therefor an executable searches NOT for libX11.so but for libX11.so.1. The second point to mention here is that these 'runtime shared libs' are NOT located in /usr/lib. You could add their path to LD_LIBRARY_PATH, but this might cause other (non-X386) applications break since there might be a application that also uses a libX11.so.1 that is incompatible to the X386 one's. The primary idea is to include the absolute sreach path into the binary, without breaking the use of LD_LIBRARY_PATH. This is done by setting the varibale LD_RUN_PATH while linking the new application to /usr/lib/X11/X386/lib: LD_RUN_PATH=/usr/lib/X11/X386/lib export LD_RUN_PATH (do this before typing 'make' !!!) What happens then ? Simply the linker places this sreach path in the binary of the application. The dynamic linker then searches FIRST this path and THEN the usual path (LD_LIBRARY_PATH).