No -R in MacOS X's ld

[DrMcCoy]

Spawned off from here:

MacOS X's ld64-97.17 doesn't understand -R<dir>, thus -Wl,-R in BOOST_FIND_LIB() fails. Instead, it wants -rpath <dir>. That also works with GNU ld 2.21.0; however, I'm unsure about its portability.

The GNU ld manpage does seem to suggest that -R on a directory is only a compatibility option, and -rpath would be more correct:

For compatibility with other ELF linkers, if the -R option is followed by a
directory name, rather than a file name, it is treated as the -rpath option.

However, it also suggest that -rpath=<dir> (note the = instead of a space) would be correct, but that's also rejected by MacOS X's ld.

[tsuna]

Thanks for filing the issue. I think we should do a little bit of research to see how other widely used Autoconf macros handle this issue, as surely others must have stumbled on it and scratched their head on the very same questions before us. From what I recall, using -Wl,-rpath -Wl,/path/to/dir is fairly portable (at least in environments that use gcc).

Actually, now that I think about it, I'm pretty sure Libtool already has some logic around this flag. We should dig in the code of libtool to find out what it does.

[dkirkby]

Just to add another voice: I am using Mac 10.6.7 with gcc 4.2.1 and I see the same problem, which prevents me from using $(BOOST_*_LDFLAGS) in my Makefile.am, or from testing for BOOST_FILESYSTEM in configure.ac. Unfortunately, I am a newcomer to the autotools so don't have much to offer towards a solution, but I really appreciate the benefits of integrating boost into the configure framework.

[tsuna]

I created a new branch called rpath_bug that contains this commit: ab15919 – can you guys test it and tell me whether it works for you?

It relies on Libtool in order to find the right flags to use to hardcode library paths for the current platform.

[dkirkby]

Your rpath_bug branch works great for me, thanks! I am now getting BOOST_*_LDFLAGS = -L/usr/local/lib and BOOST_FILESYTEM is also working now.

[DrMcCoy]

Sorry for the late reply.

That change sadly doesn't work for me, on amd64 Debian GNU/Linux, gcc 4.6. config.log says:

g++: error: unrecognized option '-rpath'

Seems like it's missing a "-Wl,"?

[tsuna]

Could you pastebin the entire config.log please?

[DrMcCoy]

https://gist.github.com/42d2d98e9b03f2a47a83

[tsuna]

Thank you. This indicates that I'm doing something wrong because Libtool itself is able to find the right flag combination.

configure:10061: checking dynamic linker characteristics
configure:10576: gcc -o conftest -g -O2   -Wl,-rpath -Wl,/foo conftest.c  >&5
configure:10576: $? = 0
configure:10810: result: GNU/Linux ld.so

I will review Libtool's code once more to find out how to properly use its variables. I have a sneaking suspicion that I need to borrow its $wl variable or whatever it was.

[tkren]

there is some information regarding Debian and -rpath: http://wiki.debian.org/RpathIssue

[RhysU]

After 7d76670 (which uses -Wl,-R instead of -R) libtool no longer adds -R flags to libsomething.la's dependency_libs field. Consequently binaries which depend on convenience or shared libraries will not have RPATH set correctly when installed.

Not sure what I am suggesting-- just want to alert y'all to the issue.

[RhysU]

(having reviewed the reports a bit more.) If the users reporting issues #15 and #19 are using libtool correctly, then how is the fact that GCC dislikes -R and wants -Wl,-R anything but a libtool problem? Libtool should be the tool accepting -R and then translating it into whatever the local compiler/linker expects. Especially since boost.m4 requires libtool according to the README. No need to query libtool for the appropriate flags and no need to update boost.m4 using -Wl,-R (which again breaks libtool's dependency_libs feature).

Thoughts?

[DrMcCoy]

Errrr, but the problem is that boost.m4 is actively calling gcc (and not libtool) with -Wl,-R, which is wrong because Mac OS X's ld wants --rpath and not -R.

I repeat: The problem is neither that libtool is somewhere else called incorrectly nor that GCC doesn't like -R (or rather, not anymore. It still holds true though). The problem is that Mac OS X's ld wants --rpath but boost.m4 gives it, directly using GCC and not libtool, -R.

[RhysU]

I'd missed that detail, sorry. My mistake. LT_OUTPUT (http://www.gnu.org/software/libtool/manual/libtool.html#index-LT_005fOUTPUT-116) followed by mucking with the resulting config.lt, I suppose.

[RhysU]

https://github.com/RhysU/boost.m4/commit/b3d58434b5e2a1a598357e83b808c8cebfb54b1e may be a fix for the problem described here. I'm interested in any feedback about its effectiveness.

[vslavik]

It's not even configure's job to set runtime options such as rpath; ideally, this should be done at all.

At the very least, it definitely shouldn't be done (and neither should -L be added) if the libraries are already on standard search path (e.g. /usr/lib or as in my case, /usr/local/lib). (This may be what was intended, judging from the code, but in my code, it mis-detects the location as /opt/local/bin and insists on putting it to the flags.)

[phs]

Echoing DrMcCoy, my first attempted fix was to replace -Wl,-R$boost_ldpath" with -Wl,-rpath $boost_ldpath". This caused problems for me, however, with non-convenience libtool libraries on ubuntu, see http://stackoverflow.com/questions/11167748 .

Using -Wl,-rpath -Wl,$boost_ldpath" instead works correctly on both ubuntu 12 and osx lion.

[vslavik]

Using -Wl,-rpath -Wl,$boost_ldpath" instead works correctly on both ubuntu 12 and osx lion.

It works "correctly" only as far as you being able to compile, but it still inserts RPATH records into the binaries (that you may want to distribute to other machines than yours) and they have no business being there, point to some path on some developer's system that doesn't exist on the user's.

[phs]

I believe the intent is the user uses ./configure && make && make install on the destination system, unless they are cross compiling. I'm aware auto* & libtool have cross compiling support, but I haven't looked into it and suspect I'm not using it.

[vslavik]

I believe the intent is the user uses ./configure && make && make install on the destination system

Seriously? Maybe twenty years ago, but these days, end users just install binaries. Binaries than somebody has to compile. And if the sources use configure and check for boost with this, you get the problem I talk about.