From 93fb2a6ef94586a571af1766677e3ca5b0d44104 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Fri, 20 Mar 2015 12:55:24 -0400 Subject: 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. --- build.txt | 57 +++++++++++---------------------------------------------- 1 file changed, 11 insertions(+), 46 deletions(-) (limited to 'build.txt') 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 -- cgit v1.2.1