Added rpath post.

diff --git a/posts/rpath.mdwn b/posts/rpath.mdwn
new file mode 100644 (file)
index 0000000..403e5e6
--- /dev/null
+++ b/posts/rpath.mdwn
@@ -0,0 +1,70 @@
+[[!meta  title="RPATH, RUNPATH, and dynamic linking"]]
+
+Recently I've been working on the [[Comedi]] ebuild in my [[Gentoo
+overlay]], wrestling with the following error:
+
+    * QA Notice: The following files contain insecure RUNPATHs
+    *  Please file a bug about this at http://bugs.gentoo.org/
+    *  with the maintaining herd of the package.
+    * /usr/lib:/var/tmp/portage/sci-libs/comedilib-9999/work/comedilib-9999/lib/.libs usr/lib/ruby/site_ruby/1.8/i686-linux/comedi.so
+
+While tracking this down the source of this error, I learned a lot
+about dynamic linking on Linux, so here's the condensed version.
+
+`RPATH`, `RUNPATH`, and `LD_LIBRARY_PATH`.  The current state of
+affairs is well summarized on the [Debian wiki][wiki], which lists
+the library search path:
+
+1. the `RPATH` binary header (set at build-time) of the library
+   causing the lookup (if any)
+2. the `RPATH` binary header (set at build-time) of the executable
+3. the `LD_LIBRARY_PATH` environment variable (set at run-time)
+4. the `RUNPATH` binary header (set at build-time) of the executable
+5. `/etc/ld.so.cache`
+6. base library directories (`/lib` and `/usr/lib`) 
+
+There was a big dust-up between Debian and libtool back in 1999 when
+libtool-generated `RPATH`s caused problems during the libc5 to libc6
+transition.  The [mailing list discussion][list] makes for amusing and
+informative reading, if you've got a spare hour or two ;).  If not,
+you should at least read the opening post, the description of
+[competing][c1] [contracts][c2], and Buddha Buck's description of [how
+linking works][works], although I imagine things might have changed
+since then.  The Debian / libtool compromise (don't set RPATH by
+default for directories in the dynamic linker search path) was
+implemented in libtool 1.5.2 (released in 2004, see the [Debian
+wiki][wiki]), so this is not as big an issue as it once was.
+
+By the way, it looks like `RUNPATH` was added since 1999 as a version
+of `RPATH` that did not override `LD_LIBRARY_PATH`, which is good,
+since `LD_LIBARY_PATH` gives you a way to link against libraries in,
+say,
+`/var/tmp/portage/sci-libs/comedilib-9999/work/comedilib-9999/lib/.libs`
+to test your executable before installation.
+
+Anyhow, [issues with rpaths persist][persist].  Since it both hard to
+predict all installation configurations at compile time, and tools to
+change rpaths later on (i.e. `chrpath`) aren't able to increase the
+size of the rpath string on Linux ([they can on Solaris][solaris],
+because Solaris leaves a bit of padding at the end of the dynamic
+string table in the compiled [ELF][] file).  This means you will have
+trouble moving a library out of the standard library path into some
+out-of-the-way location.  However, in the more common case of
+installing a library *into* the standard library path, `chrpath` is
+the tool you need, and it solved my comedilib QA issue.
+
+Along the way, I ran across two other interesting posts by Diego
+Pettenò about not [bundling][] [libraries][].
+
+[wiki]: http://wiki.debian.org/RpathIssue
+[list]: http://www.mail-archive.com/debian-devel@lists.debian.org/msg61772.html
+[c1]: http://www.mail-archive.com/debian-devel@lists.debian.org/msg61787.html
+[c2]: http://www.mail-archive.com/debian-devel@lists.debian.org/msg61796.html
+[works]: http://www.mail-archive.com/debian-devel@lists.debian.org/msg61967.html
+[persist]: http://blog.flameeyes.eu/2010/06/20/the-why-and-how-of-rpath
+[solaris]: http://blogs.sun.com/ali/entry/changing_elf_runpaths
+[ELF]: http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
+[bundling]: http://blog.flameeyes.eu/2009/01/02/bundling-libraries-for-despair-and-insecurity
+[libraries]: http://blog.flameeyes.eu/2009/03/23/bundling-libraries-the-curse-of-the-ancients
+
+[[!tag tags/linux]]