Fix issue #19 by testing both -R and -rpath to see which one ld(1) accepts.

This method of fixing issue #19 is less dependent on libtool’s internals. Once a boost library has been found and is verified to be link-to-able by specifying its path with -L, and if the test between -R and -rpath has not been performed before, now boost.m4 will first try out the same linking scenario with -R and then with -rpath and, otherwise, will exit with an error.

I know there are other fixes for this, including your other branch which hackily assumes that the user of boost.m4 is invoking libtool’s m4 macros, etc. However, this method of directly testing if linking works when -Wl,-R or -Wl,-rpath are added to LDFLAGS should not break when libtool’s internal macros are updated. It would be ideal if libtool had an autoconf macro which would set an AC_CACHE value to the correct -rpath flag, but it doesn’t.

Also, this approach should help continue to support side-by-side outside-of-ld.so.cache boost installations, unlike the first patch attached to https://bugs.gentoo.org/show_bug.cgi?id=460362 which just drops -R altogether.

It would be nice if boost.m4 could at least pick some sort of fix for issue #19 and roll/tag a new release. That way, developers who use boost.m4 will start producing packages with working ./configure scripts instead of requiring users to pull over a custom boost.m4 with the fix, etc.… ;-)

This change was tested on Mac OSX(Darwin) and Linux. It was not tested with prefixed libboost installs. An example of the output produced on Mac OSX is:

    binki@Zoidberg ~/boost.m4-issue-19/boost.m4 $ grep -e -Wl Makefile
    BOOST_DATE_TIME_LDFLAGS = -L/usr/local/lib -Wl,-rpath,/usr/local/lib