I've been developing a Cocoa app that uses both the libav* and ImageMagick C libraries but am having issues actually distributing the app. I have linked to the various static libraries in Xcode like so:
The app builds and runs perfectly fine on my machine. Now I am trying to run it on a different computer. I archived the build, and exported it as a macOS app in Xcode, which leaves me with the .app archive. Now, when I try to run it on a different mac, I get the following error:
If I run otool -L binary_name on the built binary, I get a .dylib for every single one of the included .a files. I thought the whole point of a static library was that it gets built into main binary, and that there is then no need to do any dynamic linking. Why is it still trying to load the dylib?
I managed to resolve this issue, and believe it was due to the technical note listed here: Using static versions of existing dynamic libraries. Since the dependencies I am using were installed via homebrew, the lib folders of each dependency had both the .a and .dylib files, and Xcode was linking using the dylibs. To fix it, I copied all the .a files that I needed to a separate folder and adjusted my Library Search Paths in Xcode to point to the new folder. The app now builds and links to the static libraries as it should.
Related
I'm trying to run an IOS app created by another dev that is using a cocoapod from a private repository I have no access to. I managed to extract the .framework bundle from the IPA and add it to the xcode project but it is not being recognized (I get "No such module").
Is it possible to do what I'm trying to achieve?
So far, what I've tried:
build it in release as I guess the framework in the IPA is in release
add the .framework as embedded binary
add the .framework as Linked Framework and Libraries
copy the .framework to ~/System/Library/Framework
update the Frameworks Search Path including $(SRCROOT), recursive, hardcoded paths, etc.
change the .framework location to "Relative to Build Products"
Thanks!
It wasn't that much easy to get the frameworks used in project from ipa file.
Whenver the application runs for first time, also when you archive your application, all the linked .frameworks will get converted to .dylib that is dynamic libraries.
What is static library - a unit of code linked at compile time, which does not change.
What is dynamic library - a unit of code and/or assets linked at runtime that may change.
Framework - A framework is a hierarchical directory that encapsulates a dynamic library, header files, and resources, such as storyboards, image files, and localized strings, into a single package. Apps using frameworks need to embed the framework in the app's bundle.
Dynamic Library
A dynamic lib file is just resides inside the framework folder.
Following is a description from apple documentation
Dynamic libraries outside
of a framework bundle, which typically have the file extension .dylib,
are not supported on iOS, watchOS, or tvOS, except for the system
Swift libraries provided by Xcode.
Ref: Documentation
So you cannot simply copy a .dylib to xcode bundle and just use it. There is some sort of security too.
Another approch
It is possible to decompile the source code from .ipa files. You will get idea from below links.
SO Question regarding decompiling of ipa file
Decompilation Possibility
It seems that when an app is archived for distribution, the Headers and Modules folders are removed from the .framework bundle.
The Header folder contains the .h headers for Objective-C and the Modules folder contains the .swiftmodule equivalent files for Swift.
Without these files you have no public API to consume for the framework binary, so unfortunately this renders the frameworks unusable without reverse engineering.
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'm writing an application in which I want to use free image to load files. I am on MacOSX 10.8.2 and I am using the mac ports version of free image. I had it working, but when I tried putting it on another computer without the port, it wouldn't run because it didn't have the files. The macports version comes with a dylib, can I use that to run it without downloading the port? If I can how would I compile it with the project because I have tried linking it as a Binary Library, but I can't include the files. Any help would be appreciated, as I have bee at this for a few hours now.
Thanks
You can actually build the FreeImage library as a static library. Unfortunately, the downloadable source from the http://freeimage.sourceforge.net/download.html website uses makefiles that are expecting to use the older SDKs for Xcode3.
I actually updated the Makefile.osx to build with Xcode4 using the 10.7 SDK and posted the change to https://gist.github.com/AhiyaHiya/5105571
You should be able to run this make from Terminal.app and create your .dylib and .a files for your needs.
I have written a simple application using the GPhoto2 Framework, and this works so long as the framework is in the location where it was originally compiled. I would like to move this inside the app bundle, though, so it does not need separate installation, so I need to make it work relative to this main executable.
Unfortunately the framework is not an Xcode project. It uses a script to build, so I cannot simply change the installation directory build setting, which is the solution that I have frequently seen while searching for an answer. Being quite new to Xcode and Mac programming it is also beyond my abilities to know how to convert the framework into an Xcode project.
The other advice I came across was to use install_name_tool to update the library ID and dependencies, replacing the absolute paths with ones of the form "#executable_path/../Frameworks/GPhoto2.framework". The framework is not a single binary, but contains a number of .dylib and .so libraries, but updating all of these has only been half successful.
I have set Xcode to copy the framework into the app bundle when it builds it. Then if I remove the framework from its originally compiled location the application fails to load, with the report generated by OS X saying the libgphoto2 library can no longer be found, as to be expected.
If I then use install_name_tool to update the references in all of the framework libraries inside the app bundle, and also in the app binary itself, then the application will load but fails to find any camera connected. Using otool I am able to verify that all references have correctly been changed.
But if I replace a copy of the framework to its original location it then works properly again, recognizing connected cameras, regardless of whether that framework uses relative or absolute locations. Clearly it is still looking at this location despite loading. I have even tried removing each of the individual library files from the framework in its original location in turn to see if the problem was just the result of a dependency in of these, but no matter which is missing the app will not work.
Incidentally, if I build the app using an updated version of the framework, it fails saying it cannot find the library "#executable_path/../Frameworks/GPhoto2.framework/prefix/lib/libgphoto2.2.dylib"
Am I doing something wrong or missing a step, or is what I am trying to do impossible for frameworks created outside Xcode?
In case someone comes across this future, the answer to my question was that I was doing nothing wrong. The problem was that the .so files were being loaded by libtool ltdl, at it requires absolute paths so these were being set at build time.
I patched the files gphoto2-abilities-list.c and gphoto2-port-info-list.c so that at runtime it would combine the relative library paths with the executable location. As a result I also needed to increase the FILENAME_MAX constant to allow it the mail application to run from, for example, the Desktop. But this, along with the use of install_name_tool allowed me to add GPhoto2 as a framework inside my application without needing any external dependencies.
The final problem of not being able to build my app in XCode with the framework after using install_name_tool remained, but for that I just used the original framework build, then after compilation I updated the references in the copied framework at the same time as I updated the ones in the main executable.
I want to share my Xcode project as a static library for other people to use in the xcode emulator (giving them as little raw source code as possible). How do you use an AppDelegate from a .a library file in Xcode or UIBuilder?
I copied the main Window.xib file to a new project and included all of the other source files in a static .a library that I thought I would be able to invoke somehow. What do I have to do to launch my main product that is compiled into the .a library from a brand new Xcode project that is including that library?
You'll have to link to the static library. Include it in your new Xcode project, and then in the target for the application, go to the General tab and set the library as linked. You'll probably want to copy it into your new project's bundle (in the Frameworks directory), using a Copy Files build phase. You'll also need to reference the header files for the static library for avoid warnings.
This is a much better solution found in someone else's question:
iOS Question. Can I distribute the Xcode simulator versions of my app?