I'm trying to package a pre built binary into a Mac OS application bundle and I need to change the dylib and framework search paths for the executable. Unfortunately I can't rebuild the binaries at this point which makes means I have to find a work arround rather than using the correct search paths from the outset. Does anybody know how I can do this?
I assume that you want a permanent change to the executable. You can get temporary changes using the environment variables described in dyld(1). But for a permanent change, you can modify the executable using install_name_tool(1). See Creating Working dylibs for a good short writeup on how to do it. See the dyld(1) page for the replaceable variables you can use, such as #executable_path and #loader_path.
Related
We have a project which dynamically links against several dylibs. When copy the build to another mac. One need to run "otool" over the dylibs and executable in order to fix the shared library paths in them during "install".
Looks like OSX had some strange requirements for DLL to DLL pathing that made relative paths not work in them (i.e: using rpath). My questions here:
what is the the normal way to ship a software on mac? i.e: when running either a .pkg or .dmg installer, how one make sure the dylibs installed are able to link against each other in relative path? the dylib path must be fixed with either the rpath or some post install scripts
if we are not allowed to run a post install script to fix this, what are the other options?
Relative paths should work just fine. For example assume a macOS application bundle. The application lives in Contents/MacOS while the library lives in Contents/Frameworks. In this case you would relink the application's libraries to something like this #executable_path/../Frameworks/library.so. If you don't use an application bundle but have all files in the same directory simple using #executable_path should work too.
No need to use #rpath in these examples. you can use this too but it requires the application to define this path. This may be helpful if you want to distribute a library and people are supposed to link to your library. That way they can give an #rpath in their application to find the library without otool-ing them.
And you of course you make these changes before your package up your application into a .dmg or .pkg.
I am trying to build a program that requires SDL. I have downloaded SDL for Windows so that I have a folder containing the include and lib suborders.
When I run CMake I get the following error:
Could NOT find SDL (missing: SDL_LIBRARY SDL_INCLUDE_DIR)
This is despite the fact that I have created two environment variables called SDL_LIBRARY and SDL_INCLUDE_DIR, pointing to the lib and include folders respectively.
I have no idea what to do.
In my experience, the best method when find scripts don't work as expected is to check their source code. Often you will identify the problem by just reading through the documentation at the top, but if that still doesn't work out, digging into the source is often the only thing that helps.
From the documentation alone you can see for instance, that CMake does only consider one environment variable SDLDIR for searching. SDL_INCLUDE_DIR and SDL_LIBRARY are the names of the CMake variables to hold the results of the find script. You can set them via the command line (or the cmake-gui), but I would advise against that, as it kind of undermines the purpose of using a find script in the first place.
Instead, verify that your directory structure corresponds to what the find script expects and simply set SDLDIR accordingly.
Please note that the script that currently ships with CMake does not work with the newer SDL2. If you are using SDL2, you will have to write your own script.
Please forgive me if I'm missing something obvious here. I'm developing some applications for another platform, and all of my proprietary libraries are installed to /app/lib. To facilitate this, I specify a runtime library path for each of my binaries as "/app/lib". This works fine; however, it requires that the path "/app/lib" exist in my build environment when linking (even though that directory is empty). I'm using NetBeans, which might be complicating matters, but I can see "-Wl, -rpath /app/lib" being passed to gcc.
I'd like to avoid the need to create an empty "/app/lib" in my build environment, but I don't want to change the file structure on my target platform. If I delete /app/lib from the build environment, I get an error when building that it can't be found. Is there a way to specify a runtime search path without the need for it to exist at link time?
I think the option you are looking for is -Wl,-rpath-link,/path/to/libraries. You need to use both options at once.
The linker will then use -rpath-link to find the libraries at link-time, but it'll encode the -rpath value into the binary for use at run time.
The syntax should be "-Wl,-rpath -Wl,/app/lib" ("-Wl,-rpath,/app/lib" works too). This is a bug in NetBeans. The reason why it's not more critical (and why I didn't notice this before) is that link-time search paths appear to carry over into runtime. Because NetBeans isn't placing a comma between -rpath and /app/lib, /app/lib is being interpreted as a link-time search path. As a result, my dependent libraries are still found at run-time in the appropriate location, but because it's a link-time dependency, the linking fails because /app/lib doesn't exist.
I've written a CMake module to find libclang:
find_path(LibClang_INCLUDE_DIR clang-c/Index.h)
find_library(LibClang_LIBRARY NAMES clang)
But I've installed libclang via MacPorts to /opt/local/libexec/llvm-3.0/lib and /opt/local/libexec/llvm-3.0/include. Since this isn't a normal system location, CMake doesn't find it.
What's the best way to show CMake where it is? How can I find out where CMake is searching? I don't think moving the library to a more normal location is an option because I don't want to move things away from where MacPorts put them, and I also have Apple's official clang binaries (not including libclang) on my system.
Add the HINTS or PATHS flag to suggest locations for it to search.
If you want to make a general way to include non-standard locations, you can do two things. One is make sure the users know to put the non-standard location on the LD_LIBRARY_PATH environment variable and then suggest that as a HINT to find_path and find_library with ENV LD_LIBRARY_PATH.
The other option is to put a custom environment variable and tell users to set that if it's non-standard. For instance, CLANG_ROOT, and include that in the HINTS.
Of course, you can do both and it would be the most general.
I have a project that uses OpenAL. The project is built against the 10.5 SDK, and the version of the OpenAL.framework in 10.5 causes some problems. I want to link to a custom-built version of the OpenAL.framework that resides in my source tree.
However, Xcode resolutely refuses to do this. No matter what I try, it insists on linking to the framework located at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/OpenAL.framework/OpenAL. Here are a couple of things I've tried without success:
Set the path to the framework directory in a variety of ways (relative, absolute) using -F.
Pass the linker the -Z flag to eliminate default link paths, then explicitly pass /System/Library further on in the link process, to ensure that it sees the system paths after my custom library path.
Build my library using a prelinking pass, and explicitly pass the library inside the framework to THAT.
According to man gcc, passing the -F parameter should be sufficient to ensure that a link path is searched before the default paths. Either this isn't happening correctly or I'm misunderstanding the problem, and it seems too simple and obvious to be a linker problem :-)