From 6e1d6bd6f51b3a66de029792433dcbfc9fe4a048 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Tue, 31 Mar 2015 09:55:06 -0400 Subject: Eliminate chrpath as a build dependency --- build.txt | 54 +----------------------------------------------------- 1 file changed, 1 insertion(+), 53 deletions(-) (limited to 'build.txt') diff --git a/build.txt b/build.txt index 7de42487..28ee66ae 100644 --- a/build.txt +++ b/build.txt @@ -241,58 +241,6 @@ 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). - -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. - == The leapseconds cache == Early in your build, the recipe will try to go over the Internet to @@ -410,7 +358,7 @@ Here are the scons switches I use: scons wordsize=32 snapshot=off arch=arm sample=shell scons -j3 prefix=/usr libdir=$prefix/lib udevdir=/lib/udev -chrpath=False gpsd_user=gpsd gpsd_group=uucp socket_export=1 +gpsd_user=gpsd gpsd_group=uucp socket_export=1 nmea0183=1 sirf=1 With the following environment variables: -- cgit v1.2.1