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).

