Boost.m4 fails to link boost::thread for Boost version 1.49.0 on OSX

[BrianAker]

Boost.m4 fails to link on OSX 10.7 with boost 1.49.0, but will work with boost 1.47.0.

[tsuna]

Please provide more details. A good starting point is providing your config.log.

[phs]

Hello, I am also seeing this error. Here is the relevant snippet of config.log: https://gist.github.com/2821907 . As you can see, the linker is failing because it does not understand the -R option (as opposed to not finding the correct library inclusion flag.) After taking a look, it appears this only shows up in BOOST_FIND_LIB.

It appears gnu ld treats -R as a synonym for -rpath, but -R is unknown to the OSX ld. OSX ld does offer -rpath which appears superficially similar, but I do not know enough about it to claim they are functionally equivalent.

[phs]

This seems to work for me (on osx)

--- a/m4/boost.m4
+++ b/m4/boost.m4
@@ -403,7 +403,7 @@ dnl generated only once above (before we start the for loops).
       LDFLAGS=$boost_save_LDFLAGS
       LIBS=$boost_save_LIBS
       if test x"$Boost_lib" = xyes; then
-        Boost_lib_LDFLAGS="-L$boost_ldpath -Wl,-R$boost_ldpath"
+        Boost_lib_LDFLAGS="-L$boost_ldpath -Wl,-rpath,$boost_ldpath"
         Boost_lib_LDPATH="$boost_ldpath"
         break 6
       else

[phs]

Ah. I just noticed issue 19 and pull request 28. The diff from pull 28 (which uses a space instead of a comma following -rpath) also works for me.

I see the reference to the remaining discussion in pull 28, and something about affecting Debian users. Will continue reading..

[phs]

The patch you suggest at https://github.com/tsuna/boost.m4/commit/ab159194e1207c04668c79eed57ba618ceb17484 works for me. I have AC_PROG_LIBTOOL declared before BOOST_REQUIRE in configure.ac

[phs]

After reading http://lists.gnu.org/archive/html/libtool/2007-11/msg00017.html and http://lists.gnu.org/archive/html/autoconf/2004-09/msg00031.html on a lark I decided to monkey-patch libtool in directly, and it worked:

diff --git a/m4/boost.m4 b/m4/boost.m4
index 3d4e47c..836a5e3 100644
--- a/m4/boost.m4
+++ b/m4/boost.m4
@@ -395,15 +395,18 @@ for boost_rtopt_ in $boost_rtopt '' -d; do
       boost_save_LIBS=$LIBS
       LIBS="$Boost_lib_LIBS $LIBS"
       test x"$boost_ldpath" != x && LDFLAGS="$LDFLAGS -L$boost_ldpath"
+      boost_save_ac_link=$ac_link
+      ac_link="libtool --mode=link $ac_link"
 dnl First argument of AC_LINK_IFELSE left empty because the test file is
 dnl generated only once above (before we start the for loops).
       _BOOST_AC_LINK_IFELSE([],
                             [Boost_lib=yes], [Boost_lib=no])
+      ac_link=$boost_save_ac_link
       ac_objext=$boost_save_ac_objext
       LDFLAGS=$boost_save_LDFLAGS
       LIBS=$boost_save_LIBS
       if test x"$Boost_lib" = xyes; then
-        Boost_lib_LDFLAGS="-L$boost_ldpath -Wl,-R$boost_ldpath"
+        Boost_lib_LDFLAGS="-L$boost_ldpath -R$boost_ldpath"
         Boost_lib_LDPATH="$boost_ldpath"
         break 6
       else

Relevant snippet of config.log is at https://gist.github.com/2822022 Notice that libtool must either be correctly converting -R to --rpath under the covers, or stripping it out completely (since perhaps /usr/local/lib is already in the list.)

[phs]

..and now I understand pull request 21. Was there a specific reason (aside from annoyance at customizing AC_LANG_PUSH([C++])) that it wasn't merged in? As an application author and so in control of my own sandbox, so to speak, are there reasons you would advise me against using RhysU's patch?