I have a fairly large project in Xcode 8.2, which consists of one big dynamic library libarc.dylib and several other executable targets. One of these targets runs the unit and integration tests on my library.
I have set the Xcode build location to be relative to my project directory, instead of the default Xcode derived data location.
Building and running my project's targets works fine from within Xcode, but when I run my tests executable, from the build product directory, via terminal, I get the following error.
dyld: Library not loaded: /usr/local/lib/libarc.dylib
Referenced from: /Users/<username>/programming/<project>/Build/Products/Debug/.Tests
Reason: image not found
[1] 44968 abort ./Tests
So obviously the dynamic library is not loading. Upon checking the local/lib path, I notice that my library is not installed.
Running otool -L Tests gives me
/usr/local/lib/libarc.dylib (compatibility version 1.0.0, current version 1.0.0)
This library is project-specific, and I would like to load it from my project Build location. Preferably, at some stage, everything will be bundled into an .app.
How can I set the dylib loading path, for the Tests target, to point to the libarc.dylib in its run path?
I have found some information, that suggests Embedding Binaries into my target, but as of Xcode 8.2, I can not find this section under the General tab, for my target.
Beyond just converting my library to a static library, what other options do I have? I don't think its appropriate to have the library installed system wide in the release. Would a static library be more appropriate, given my requirements. I'll also add, the library consists of a game engine, so performance is key.
As a final note, many of the engine core systems are implemented as singletons.
Related
I'm trying to build wxWidgets library into a custom path on a Fedora 27 operative system.
I achieved the wx-config file path recognition and works with the cmake execution. Also, I load libraries and include dirs based on modified wxWidgets finder cmake file that sets thewx-config custom path successfully.
But cmake does not load my wxWidgets configuration. I mean, wx_gtk2u_jpeg-3.1 builded lib could not be founded (suposed to be /usr/lib/libwx_gtk2u_jpeg-3.1.so). I need jpeg dependency from wxWidgets for my project.
I'm sure that problem is not about cmake files. However, the problem is wxWidgets compilation because cmake can found the other builded dependencies into /usr/lib/
I actually installed the libjpeg-turbo-devel package that includes the libjpeg.h needed for wxWidgets building without success of libwx_gtk2u_jpeg-3.1.so creation.
The weirdest part is that $ wx-config --libs shows the wx_gtk2u_jpeg-3.1 lib to be linked and the hint paths that it should be founded.
wxWidgets commands for building:
$ ./configure --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin --with-zlib=builtin --with-expat=builtin --enable-webviewwebkit=no --prefix=/opt/cpp_dependencies/2018Q1/usr'
$ make -j 4
$ make install
You can check out my cmake files, the cmake output and wxWidgets building output in order to reproducing it: https://gist.github.com/jjalvarezl/b70accae269ef56c56010bedf157c27f
You can see line 1543 of wxWidgets building output file that jpeg library is buildin, and, 1564 of same file, the make install command that installs all libwx_<lib_name>.so libraries into final /usr/lib path. Anyway, no one contains the needed library.
Please show the exact error message, as it's not clear what the actual problem is. What I can say, is that the different built-in versions of 3rd party libraries, such as libjpeg, are always static libraries, even when wxWidgets themselves are shared. I.e. you're never going to have libwx_gtk2u_jpeg-3.1.so, only .a.
I'd also strongly recommend using system versions of the 3rd party libraries under Unix systems. This means that your wxWidgets applications will get security updates from your OS vendor and you don't risk running into any incompatibilities due to using 2 different versions of the same library in your application.
Goals
I added Command Line Tool target to an iOS app and linked with swift frameworks. (tested with Realm and SwiftyJSON)
Expected Results
Build Command Line tool with those libraries.
Actual Results
Xcode output:
dyld: Library not loaded: #rpath/libswiftCore.dylib
Referenced from: .../Xcode/DerivedData/.../Build/Products/Debug/RealmSwift.framework/Versions/A/RealmSwift
Reason: Incompatible library version: RealmSwift requires version 1.0.0 or later, but libswiftCore.dylib provides version 0.0.0
Steps to Reproduce
Create empty Swift Command Line Tool and link Realm frameworks
Code Sample
CommandLineTest.zip
Version of Frameworks and Tooling
Realm version: github "realm/realm-cocoa" "master"
SwiftyJSON version: github "acegreen/SwiftyJSON" "swift3"
Xcode version: 8 GM (which is on the App Store)
Dependency manager + version: Carthage 0.18
Command-line tools are best with static archives because everything is distributed as a single binary. Looking at Realm, I don't see that there is a static archive option. They do have an iOS static framework that I got compiling for macOS but that's not quite what you want. You might want to try playing with Realm's source a bit more to see if you can get it to produce a static archive.
In the mean time, as a workaround, you'll need to tell Xcode where to find the dylibs at runtime and also to install them somewhere.
In your Build Settings, go down to "Runpath Search Paths" and add "#rpath".
In Build Phases, under Copy Files, click the + button and add both Realm.framework and RealmSwift.framework from your project.
Because Realm is compiled with an older version of Swift, you also need to specify "Use Legacy Swift Language Version" in Build Settings.
That will get your project building and finding the Realm libraries but now it will fail to find libswiftCore.dylib. That's because normally command-line tools are statically linked with the Swift library but as soon as you add a framework/dylib, the linker no longer includes the static version.
Go back to Build Phases, Copy Files, and add the following:
libswiftObjectiveC.dylib
libswiftIOKit.dylib
libswiftFoundation.dylib
libswiftDispatch.dylib
libswiftDarwin.dylib
libswiftCoreGraphics.dylib
libswiftCore.dylib
You can find them inside your Xcode installation and then ./Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/macosx/
WARNING: Keep in mind that you will need to distribute the frameworks and the dylibs with your command-line tool and they will need to be in the same directory as the tool. You can put them somewhere else on the system by specifying a different runpath but you'll still need them distributed with your tool.
The nice thing about a .app bundle is that it gives you a place to put this stuff and users can just drag-and-drop it to install it. If you could get a static archive version of Realm, you could distribute everything in one binary.
TL;DR
Objective-C app linked with static library that dynamic links Boost Filesystem. App can be run from output directory using Terminal, but trying to run from Xcode debugger or Finder gives error dyld: Library not loaded: libboost_filesystem.dylib <snip> Reason: image not found.
Problem
In my Xcode project I have a structure that looks like this:
MainProject (Objective-C)
- static_lib_that_uses_filesystem (C++)
To get everything to link, I added libboost_system and libboost_filesystem dylibs to the "Link Binary with Libraries" build phase in MainProject.
When I try to run the app from either Xcode or Finder I get:
sharedlibrary apply-load-rules all
warning: Unable to read symbols for libboost_filesystem.dylib (file not found).
warning: Unable to read symbols from "libboost_filesystem.dylib" (not yet mapped into memory).
warning: Unable to read symbols for libboost_system.dylib (file not found).
warning: Unable to read symbols from "libboost_system.dylib" (not yet mapped into memory).
[Switching to process 43957 thread 0x0]
dyld: Library not loaded: libboost_filesystem.dylib
Referenced from: /Users/ssteele/Library/Developer/Xcode/DerivedData/MainProject-dqrhyuarllykslftblocjdzxlran/Build/Products/Debug/MainProject.app/Contents/MacOS/MainProject
Reason: image not found
I added a build stage to copy the dylibs to the Frameworks directory in the bundle, this doesn't help. I changed this to copy them to the Executables directory which also didn't help.
Having them in the Executables directory does allow me to run the app from Terminal.
How can I get the app to find the dylibs when run from Finder/Xcode?
Background Info
I'm using Xcode 4.2 on Lion and currently targeting Lion only. I built my shared libraries for filesystem like this:
./b2 threading=multi macosx-version=10.7 --with-filesystem stage
This creates libboost_system.dylib, libboost_filesystem.dylib, and also .a equivalents in the stage/lib directory, I'm referencing them in the project directly from there.
Dynamic libs (dylibs) on OSX bake in the path that they should be loaded from. For example...
/usr/lib/some_awesome.dylib.
When you link to a dylib, the linker embeds this path in your executable as the place to look for it at runtime. This is fine and easy with installed libs, but for relative path linking it's more complicated.
When you build the boost libs, they just get their names embedded rather than a full or relative path (i.e. libboost_system.dylib rather than /usr/lib/libboost_filesystem.dylib). You should be able to change this with the dll-path option, but that seems broken currently.
To fix your problem you either need to get the correct path relative to your application embedded (e.g. #executable_path/libwhatever.dylib) into the dylibs somehow, which would probably require the bjam dll-path option to work, or instead you can fix your executable to look in a different location.
To do this, use something like the following as a script step in your build:
install_name_tool -change libboost_filesystem.dylib #executable_path/libboost_filesystem.dylib$BUILT_PRODUCTS_DIR/$EXECUTABLE_PATH
Note that if you have multiple dylibs that reference each other with broken paths, you'll need to fix the paths between them too, e.g.
install_name_tool -change libboost_system.dylib #executable_path/libboost_system.dylib$BUILT_PRODUCTS_DIR/$EXECUTABLE_FOLDER_PATH/libboost_filesystem.dylib
The following is a good article on this: Creating working dylibs
The issue is that boost needs to be installed e.g. b2 ..... install. This copies the libraries and headers into /usr/local/lib and /usr/local/include.
OSX dynamic libraries only run from the directory that they are built for.
You can change the install directory by using the -prefix argument to boost build. However the libraries would still need to be in the same directory for all users.
There should be a way of building boost as a framework and/or embedding #executable_path in the library.
An alternative is to use boost's static libraries - build the static only or delete the dynamic ones, Xcode looks for dynamic before static. If using static then the path to the libraries does not matter at run time as all the code is now in the executable.
I think you need to add the path to the directory where you saved libboost_filesystem.a in the "library search paths"
Click on your project profile -> build settings -> expand "Search path" -> "library search paths"
I have an application written in platform-independent C++ which has been primarily developed on Windows. I'm now trying to get it up and running on a Mac but I seem to be lost in how to link to the Mac version of a third-party library I'm using. I added the library's include and lib folders to header and library search paths respectively and it compiles/links but upon running dies with the following:
dyld: Library not loaded: #executable_path/../Frameworks/libsfml-system-d.2.dylib
Referenced from: /Users/jdoe/Library/Developer/Xcode/DerivedData/Foobar-fonhiddwdwvgqygcegiffqkontxi/Build/Products/Debug/Foobar.app/Contents/MacOS/Foobar
Reason: image not found
I can get it to run by putting the dylibs in /usr/lib but I don't think this is a good idea for distribution. How can I include the dylib inside my app bundle?
Add a copy-files build phase that copies the dylib into the Frameworks folder inside the app bundle. (When you Get Info on a copy files build phase, Frameworks is one of the destination choices.)
In the project I am working on, we provide the possibility to dynamically load additional features. For that we use dlopen.
To find this libraries we have something we call module path. There we have a default path, where the shared libraries are (a lot of them are shipped).
At the moment we have two default paths: we first look in the build directory for the shared library and afterwards in the install directory. This is because it should also be possible to run the application without installing it (so in that case it needs to look first in the build directory).
Now the problem ist, if a user builds the application from source and installs it with make install, the libraries in her build directory are loaded by default. This will result in a crash. So it only works if the user afterwards removes or renames the build directory.
No the question: is there a trick (either by C++ or by the build system) to know whether the application is installed or not. The problem is, that the functionality is implemented in a shared library and the implemented way to search for modules has to work also for other applications that link against our library (so we can not rely on the path of the executable). We use CMake as a build system.
To make the situation even harder, the solution has to work on Windows, Linux and Mac OS X.
EDIT:
I further investigated and the problem is more complicated. This is the situation:
There is a small executable a
Furthermore there is a "main" library main.so
then there is a dynamically loaded library lib.so
lib.so links against main.so
The problem is, that lib.so has the absolute path to main.so in the build directory in its rpath. Thanks to the tip of #MSalters I now was able to make a hack to make sure to load the correct version of lib.so (the one in the install directory) but since it has the build path in the rpath it loads the wrong main.so (so in fact there are two copies of main.so in the memory - this messes things up).
Is there a way to remove this reference to the build path from the library? I tried all options of cmake related to rpath without success
Can't you check where the executable itself is? If it's in the build directories, use build libraries -- if it's in the install, use install?
getcwd() has equivalents on all of those platforms, but it might not be what you want -- it depends on how you run the executable.
To get the process's location is system specific, I think, but it shouldn't be too hard to wrap that.
The installed version should not have the build directory in the rpath.
You might want to do the linking twice (once for the build version and once for the installed version). Usually, on *nix systems, the installed binary has some static path where it tries to find plugins. You might define some environment variable (or command-line argument) to overload it for the build execution (and use a wrapper script to set it in the build environment).
Check how it is solved by some projects (Firefox for example).
I don't know much about windows system but I think the standard way of doing this is to search plugins in the same directory as the executable.