MACOSX_RPATH not specified in build

[kavika13]

When using cmake to generate a makefile on OSX, I get this warning:

CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   jsoncpp_lib

This warning is for project developers.  Use -Wno-dev to suppress it.

The warning isn't the problem, though.

I'd like to have the rpath set on the dynamic libraries, because I am not planning to install the library system wide, and plan to place it in my app bundle. I can easily work around it by using install_name_tool in my build scripts to hack the library, however the build should probably just set this up to start with.

Let me know if that use case needs more explanation, or if you think that is a bad way to use the library. I can also probably fix it and submit a patch, but I want to be sure this wasn't intentional before I do.

[cdunn2001]

Merged. But are you sure that will not cause problems for anyone installing system wide?

[kavika13]

I know that the popular FMOD library sets @rpath/libfmod.dylib on their binary distribution, and I found advice from a few places on the internet saying RPATH was the preferred way to create a "relocatable" dylib on OSX, so that's why I submitted this patch.

I am not an expert on this, so I am not 100% sure, but I've done a little research after your prompting.

In a case where the application is already linked with a hard-coded system-wide library path (/usr/local/include, or what have you), and the user compiles and installs a new version of jsoncpp to the same path, I believe nothing will change. The expected loader behavior gets baked into the executable or library when you run the linker. Existing binaries would have /whatever/absolute/path/jsoncpp.1.dylib hard coded into them, and would not be broken just because the library was updated to use rpath.

In a case where a binary that depends on jsoncpp is being compiled again, and does not specify jsoncpp's install path in their binary's rpath list, and doesn't override the linker path their binary uses to find jsoncpp, then the user might run into problems in some (probably atypical) cases. The binary they are compiling will inherit the @rpath/jsoncpp.1.dylib value. When they run that binary, the loader will do rpath search behavior, which seems like it will work unless they're intentionally not using a default environment.

I looked at man dyld, and it says that if the loader can't find a dylib in the specified search paths (in this case, none), then it will consult a set of environment variables for other paths to search in. If the user specified those environment variables in their script or IDE, but didn't specify the directory jsoncpp got installed to, then they could run into issues. However, the default value for DYLD_FALLBACK_LIBRARY_PATH is $(HOME)/lib:/usr/local/lib:/lib:/usr/lib, which includes the default install path for jsoncpp, so I think most users won't run into problems. I tested this, and my executable launched and ran. I verified my test by also removing a different dylib that I hadn't installed system wide, and it broke on run, just like I expected.

The user has a work-around in cases that are breaking. They can either patch the jsoncpp binary's install path using install_name_tool, or they can set one of those dyld environment variables I mentioned above when they run their executable (see man dyld). It would also be possible to do further modifications to jsoncpp's CMake build script to patch the library when it gets installed system wide, if there was any demand for that. As far as I can tell, it would be pretty rare to run into issues, so I'm not sure if that change is necessary.

[kavika13]

This page seems to have good information on the topic, and covers some of the stuff I mentioned that I found in man dyld: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html