I need to create a Mac version of our libraries for one of our customers. I am not so familiar with dynamic libraries on Mac, but from what I understand, I have 2 options: .dylib or frameworks. What would be the best option? Why?
Few related questions:
If I understand correctly, .dylib have to be installed in one of the stnadard UNIX directories such as /usr/lib, etc. Hence using a .dylib should make my customer's installer much more complex, since they'll probably need to request permission to write something in a system folder?
Can frameworks be private and embedded within my customer's bundle? So no one else can see/use them?
Any constructive criticisms/comments/ideas more than welcome. Thanks in advance.
Alex
.dylib is similar to .so on Linux.
Frameworks are basically just the OSX way of distributing libraries and headers together. They are the Application Bundle equivalent for library distribution.
With either method if you want to ensure other people don't use them you should be using static libraries (.a files) and getting your customer to statically link them into their application.
Otherwise there isn't really much difference between Frameworks and .dylib except the prior is nicer for OSX developers.
Either can be embedded inside a customers Application bundle, otool/install_name_tool handle them both fine.
Related
I have a Cocoa application that uses OpenCV, TBB, boost and some other libraries which are installed in my system. How do I create a package that has all this inside so that customer doesn't have to install anything besides just copy/paste my package?
At the building stage they are referenced via .dylib .
Is it possible?
Where I choose in xCode Product\Archive it will only export the app itself.
well, after a lot of reading I could not find an easy solution. Maybe is there, but I didn't have more time to search for it.
So instead I wrote a small application in C++ that uses otool and install_name_tool utilities to analyze needed required libraries and copy them into the bundle. Is located here https://github.com/integral-llc/libb . Keep in mind, it was made for personal use, but can be easily changed for anything else.
It worked perfectly for my case. It found all needed dependencies for OpenCV, boost, TBB.
if you have better tools or ideas to improve current one, you are more than welcome to say.
I am working on a Qt app with some library dependencies, for which I will have to make an installer.
From everything I read, seems like the best way is to make a bundle app with all library dependencies, and the required Qt frameworks, inside myapp.app/Contents/Frameworks
There are other applications created in parallel... that will get to be deployed on mac as well. They will have the same library dependencies and will be built using the same Qt version.
In that case it makes sense for the libraries and Qt to be installed OUTSIDE the bundle... so both (all) apps have access without having multiple copies of the same libraries.
Does that seem reasonable - and do-able with mac osx concept of bundle islands ? And how would I create such an installer that places libraries outside the app bundle ?
The simplest method of deploying Qt for OS X is to use the macdeployqt command line tool, and you have identified correctly that the normal method is to place the frameworks inside the app bundle, but multiple apps will each have copies of the frameworks.
It is reasonable to suggest moving the Qt frameworks to a separate, external location and linking to that instead. However, you will need to manage the framework carefully, especially when it comes to providing updates and be aware that if the framework is removed or altered, all your applications will fail to load. This, however is the same for any framework dependent application.
The thing to consider is where to place the framework. Normally, external frameworks reside in /Library/Frameworks, but if we all start to use that for Qt, problems may occur when your app is installed and another developer installs their app's frameworks with a different version of the libraries.
Apple defines various 'key directories' for applications and initially, the most likely location would appear to be the "Application Support Directory", but the documentation states that this is for: -
any type of file that supports the app but is not required for the app to run
This location is often used for support files, such as templates for the user to select.
If your application is to be deployed via the Apple Store, I wouldn't be surprised if it is rejected if you use this location. However, you're not using the Apple Store, then you could deploy the frameworks here.
If the Apple Store is your method of deployment, then /Library/Frameworks is probably the only place acceptable for the Qt framework to reside, with the possibility of the problems I've mentioned above.
Alternatively, consider just how many applications you're developing and is it really an issue to bundle the frameworks multiple times against the advantages that it brings, such as allowing the user to cleanly remove the application and all of its dependencies, as well as reducing problems of the framework being altered or removed accidentally?
If you choose to move them externally, you can refer to the answer to this question, which comprehensively explains how to make installer packages, after having updated your binary dependencies on the frameworks with the install_name_tool, as outlined here.
I'm working on a fairly simple OS X app that uses a couple third-party libraries (SoX and TwoLAME) to do some audio converting. TwoLAME relies on libsndfile, and SoX relies on sndfile plus a number of other libraries.
For development, I simply installed the two libraries with Homebrew, which took care of the dependencies, and then linked right to them (ie in /usr/local/Cellar/...). Now that I'm ready to deploy, I need to figure out a way to get everything packaged up.
I know frameworks are a bit ambiguous in Cocoa (fake ones, dynamic ones, etc), but it seems like ideally I would end up with some frameworks of one kind or another that I can drop into the project and everything would work.
I've read through a lot of different docs and tutorials about frameworks, and tried a number of approaches, but I seem to be missing some core concept for getting this all to work together.
I have been able to make frameworks from the libraries that sort of work, in the sense that I compile from source, take the static (.a) library and put it in a "fake" framework with the headers, and the app will run with those. Those static libraries are still referencing the dependencies on my local path, though. So, eg, if I uninstall Lame from Homebrew, the SoX static library in my framework will fail.
I'm really struggling to figure out what the best way cleanly get all these libraries and their dependencies into this app. The tutorials I've seen about building dynamic Cocoa libraries from scratch have been very hard to do with the source code for these pre-existing libraries. The other option I have considered it build dylibs and then use install_name_tool to change paths to be relative just ship everything with the app and try to match everything up.
There's got to be some better way that I'm just missing, and would really appreciate any help.
I'm still not 100% sure with the framework linking process, but from what I've seen here before nobody has asked a similar question, perhaps because this could be a silly question, but I'll give it a go anyway.
In my current X-Code project, I'm using a custom framework, say example.framework. At the moment, as far as I'm aware of, in order for the program to function with the framework, I need to have it either in /Library/Frameworks, or I need to have it copied into the bundle resources in the build phase.
Would anybody know about adding a framework to a project in a way that it gets compiled into the executable, so I don't have to include the raw framework with the app? I'd rather not share the whole framework...
Thank you in advance! Any suggestions are also welcome!
A Mac OS X framework is basically a shared library, meaning it's a separate binary.
Basically, when your main executable is launched, the OS will load the framework/dylib into memory, and map the symbols, so your main executable can access them.
Note that a framework/dylib (bundled into the application or not), does not need to contain the header files, as those are only needed at compilation time.
With Xcode, you can actually decide whether or not to include the header files, when you are copying the framework to its installation directory (see your build phases).
If you don't copy header files, people won't be able to use your framework/dylib (unless they reverse-engineer it, of course).
If you still think a framework is not suitable for your needs, you may want to create a static library instead.
A static library is a separate object file (usually .a) that is «included» with your final binary, at link time.
This way, you only have a single binary file, containing the code from the library and from your project.
I have a program (specifically my entry for the SO DevDays Countdown app challenge) which relies on several dynamic libraries, namely libSDL, libSDL_ttf, and others. I have these libraries installed under /opt/local/lib via MacPorts, and many people won't have these installed (and some might have them installed, but not at that location).
How do I distribute my program so that people without these libraries installed can run it out-of-the-box? Obviously I'll have to distribute the various .dylib files, but doing this is insufficient. The dynamic loader still looks for the libraries installed at the locations I have them installed at. Is there a way to tell the dynamic loader to look in the current directory of the executable, like what Windows does with DLLs? People shouldn't have to modify any environment variables (e.g. DYLD_LIBRARY_PATH), since again I want this to work out-of-the-box.
The basic approach to this is to ship them in the .app bundle. You'll then modify the location the linker looks for shared libraries to include this.
The steps are:
Create a new copy files build phase to your target that copies those files into the Frameworks directory of the .app bundle.
Edit the build configuration setting "Runpath Search Paths" to include #executable_path/../Frameworks
If you build your executable with these changes and then look, you should find that the dylibs exist in the Foo.app/Contents/Framework directory and running otool -L Foo.app/Contents/MacOS/Foo should yield and entry prefixed by #rpath for those dylibs.
From this Cocoabuilder post:
In general, #loader_path is preferred over #executable_path, as it
allows embedded frameworks to work in both an executable and a bundle,
plugin, or sub-framework. The only downside is that #loader_path
requires 10.4 or newer. If you're on 10.5 or newer, #rpath is even
better than #loader_path.
As you mentioned you're not using Xcode, so it's a bit difficult. Here are options in my order of preference:
Switch to Xcode. Use frameworks. The SDL libraries are available as frameworks already, and I've seen more than a couple commercial games with a libsdl.framework inside the app bundle.
Use frameworks, but keep your Makefiles. Download the framework versions of your SDL libraries (or build them yourself), and link with them with the -framework linker flag. Distribute the frameworks with your app or don't, and tell your users to put them in either ~/Library/Frameworks or in /Library/Frameworks. I wouldn't bother with an installer for this.
Statically link against SDL. In the Makefile, you'll have to list the path of the static libraries rather than use the -l flag, e.g., you run "ld blah blah /opt/local/lib/libsdl.a". There is no way that I know to tell -l to prefer static over shared libraries, and believe me, I've looked.
Statically link the libraries.