Revert "Force static linking when chrpath=no."

It broke everyone's build except mine, apparently.  Back it out until we know
why.

1 files changed, 46 insertions, 11 deletions

diff --git a/build.txt b/build.txt
index 4b25260b..1f784853 100644
--- a/build.txt
+++ b/build.txt
@@ -242,23 +242,58 @@ 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 chrpath matters ===
+=== 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).
 
 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