Force static linking when chrpath=no.

Trying to deal with the poorly-documented mess that around  RPATH, RUNPATH,
and LD_LIBRARY_PATH got to be too much.

All regression tests pass.

1 files changed, 11 insertions, 46 deletions

diff --git a/build.txt b/build.txt
index 1f784853..4b25260b 100644
--- a/build.txt
+++ b/build.txt
@@ -242,58 +242,23 @@ included with the distribution. To install it, copy the file
 'gpsd.php' to your HTML document directory. Then see the
 post-installation instructions in INSTALL for how to configure it.
 
-=== Why you might need chrpath ===
-
-You can probably skip this section unless you are a developer working
-on the GPSD source directly, with a need to run some of the GPSD
-programs by hand in the test directory.  You are likely to get a
-message something like:
-
---------------------------------------------------------------------
-./gpsd: error while loading shared libraries: libgpsd.so.XX: cannot open shared object file: No such file or directory
---------------------------------------------------------------------
-
-If this happens, there are two different things you can do about it.
-One is this:
-
---------------------------------------------------------------------
-export LD_LIBRARY_PATH=${PWD}
---------------------------------------------------------------------
-
-The other is to install the chrpath utility and do your builds with
-chrpath=yes.
-
-The reason one of these is required is because of some details
-about dynamic linking.  The search path for dynamic linking that is
-compiled into your binaries as you build them is set by the
-environment variable RPATH, if it exists.  At runtime, when a
-dynamically-linked executable is called, that path is prepended
-with $LD_LIBRARY_PATH
-
-Ideally, during development, we want to build build binaries that (a)
-link dynamically, (b) can be tested in the build directory without
-installing to system space (in particular, so we can run ad-hoc
-tests without disturbing a production installation) and (c) won't
-carry a potential exploit into system space if the binaries are
-installed.
-
-The potential exploit is the remnant presence of the build directory in
-the binary's internal list of places it will look for shared libraries.
-We need that to be there for testing purposes, but we want it gone
-in the version of the binary that's copied to /lib or /usr/lib.  Otherwise
-there are threat scenarios with a maliciously crafted library.
-
-To get (b) without runtime tweaking of LD_LIBRARY_PATH, the
-development directory needs to be in RPATH, opening the security hole.
-Without editing RPATH at installation time we can get any two of those
-three, but we can't get all three. Choosing static linking we get (b)
-and (c), choosing dynamic linking without chrpath we get (a) and (b).
+=== Why chrpath matters ===
 
 chrpath is a tool for editing RPATH in object files.
 
 Ubuntu users can do 'apt-get install chrpath'
 CentOS users can do 'yum install chrpath' from extras.
 
+If you do not have chrpath available, your GPSD binaries will be
+built statically linked. (The corresponding shared libraries
+will still be built and installed for third-party programs to use.)
+
+The reason chrpath or static linking is required is because dynamic
+linking is a fragile, poorly-documented, non-portable mess that
+devoured a disproportionately large amount of GPSD maintainer
+time.  We struggled with this up through release 3.14 before
+giving up in disgust.
+
 == The leapseconds cache ==
 
 Early in your build, the recipe will try to go over the Internet to