Skip to content
This repository

No -R in MacOS X's ld #19

Closed
DrMcCoy opened this Issue April 19, 2011 · 19 comments

7 participants

Sven Hesse Benoit Sigoure dkirkby Thomas Krennwallner Rhys Ulerich Václav Slavík Phil Smith
Sven Hesse

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.

Benoit Sigoure
Owner
tsuna commented April 19, 2011

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.

Benoit Sigoure
Owner
tsuna commented April 22, 2011

I created a new branch called rpath_bug that contains this commit: tsuna/boost.m4@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.

Sven Hesse
DrMcCoy commented May 06, 2011

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,"?

Benoit Sigoure
Owner
tsuna commented May 06, 2011

Could you pastebin the entire config.log please?

Benoit Sigoure
Owner
tsuna commented May 06, 2011

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.

Thomas Krennwallner
tkren commented June 13, 2011

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

Rhys Ulerich
RhysU commented June 22, 2011

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.

Rhys Ulerich
RhysU commented June 22, 2011

(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?

Sven Hesse

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.

Rhys Ulerich
RhysU commented June 22, 2011

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.

Rhys Ulerich
RhysU commented June 29, 2011

RhysU@b3d5843 may be a fix for the problem described here. I'm interested in any feedback about its effectiveness.

Václav Slavík

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.)

Phil Smith
phs commented June 23, 2012

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.

Václav Slavík

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.

Phil Smith
phs commented June 23, 2012

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.

Václav Slavík

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.

Benoit Sigoure tsuna closed this issue from a commit March 05, 2013
Nathan Phillip Brink Fix Mac OSX ld support by detecting whether to use -Wl,-R or -Wl,-rpath.
This fixes #19.

Signed-off-by: Benoit Sigoure <tsunanet@gmail.com>
ee15a2a
Benoit Sigoure tsuna closed this in ee15a2a March 04, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.