I have a C program that I build using Makefiles on OS X and I'd like to add the version/build number so that it is included in any crash reports. How can this be done without putting the binary as part of an app bundle?
As you may have realised, the standard OSX method is to create a bundle and add the version in the Info.plist and there isn't the usual attributes available within the binary executable, as you'd find in Windows.
Many terminal apps will allow you to discover their version with a -v option, but this is usuallly just a function returning the version number.
If you want to add meta data without hard coding it, you could use the extended file attributes to store the version number, which you can read, write and view with the xattr command.
Related
I need to accomplish following three things. I am not sure how to go about it using Swift and Xcode
Package an existing CLI tool with the APP.
Use swift to issue commands to this CLI app and let it do its thing.
Read the output stream coming from the CLI app in real-time if possible.
I have found NSTask that should be utilized, but I get App Previlege Issues and errors. SMJobBless sounds helpful but I am having hard time to understand all this. All I was trying to do was issuing some commands to a cli app that is already embedded within my app package.
If you are looking to package a Command Line Tool you already wrote and have it run as root, that it is possible to do by installing it with SMJobBless but it's going to involve a bit of work. When installing a Command Line Tool in this manner, Apple refers to it as a helper tool. (Sometimes a privileged helper tool.)
For SMJobBless to succeed, Apple requires the following:
Your app must be signed.
The helper tool must be signed.
The helper tool must be located in the Contents/Library/LaunchServices directory inside your app's bundle.
The filename of the helper tool should be reverse-DNS format.
If your app has the bundle identifier "com.example.YourApp" then your helper tool may have a
filename of "com.example.YourApp.helper".
The helper tool must have an embedded launchd property list.
The helper tool's embedded launchd property list must have an entry with Label as the key and the value
must be the filename of the helper tool.
The helper tool must have an embedded info property list.
The helper tool's embedded info property list must have an entry with
SMAuthorizedClients
as its key and its value must be an array of strings. Each string must be a
code signing requirement.
Your app must satisify at least one of these requirements.
Only processes which meet one or more of these requirements may install or update the helper tool.
These requirements are only about which processes may install or update the helper tool. They impose no
restrictions on which processes can communicate with the helper tool.
The helper tool's embedded info property list must have an entry with
CFBundleVersion
as its key and its value must be a string matching the format described in CFBundleVersion's documentation.
This requirement is not documented by Apple, but is enforced.
While not documented by Apple, SMJobBless will not overwrite an existing installation of a helper tool with one
that has an equal or lower value for its CFBundleVersion entry.
Your app's Info.plist must have an entry with
SMPrivilegedExecutables
as its key and its value must be a dictionary. Each dictionary key must be a helper tool's filename; for example
"com.example.YourApp.helper". Each dictionary value must be a string representation of a code
signing requirement that the helper tool satisfies.
If you want to see a sample project that is configured to satisfy these requirements, you can take a look at SwiftAuthorizationSample.
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.
I've created an OpenGL application using the Command Line Tool project template.
Now the output project is obviously a unix executable.
My question is How can I convert this executable into a bundle .app?
Have I to add another target?
If you created a command line tool, it is just that, a command line tool. I don't know of any way to bundle it up into an application with ease.
If I were you, and you are going to start writing Mac OpenGL application, get set up with SFML. It greatly simplifies window creation, is cross platform and has a great community. Also, getting to the resource path in a mac .app bundle is a bit tricky and the templates they provide allow you to access any file with a call:
loadFile(resourcePath() + "filename.txt");
rather than having to keep track of everything. Plus, the whole resource path code is written in objective C which can be a pain for some C++ programmers.
The whole framework is pretty robust but maintains a simplistic style and its own namespace. Use what you want, don't use what you don't need. The latest version (still beta) 2.0, comes with Xcode templates. Just create a template and in build settings for your project, scroll to the bottom. You'll see SFML_LINK_DYLIBS_SUFFIX and it has a value of '-d'. Remove the '-d' and it should compile.
Then if you are distributing, add a copy files build phase and link the .dylib(s) that you used.
On Mac OS X, binary executables in the DYLD format contain "loader commands" that instruct the library loading system how to handle the contents of the file. In particular, the loader command instruct the system where dependent libraries should be searched for, etc.
You can see the complete list of loader commands for any binary on your system by running "otool -l /path/to/your/app".
Generally speaking these loader commands are set by the "ld" tool during the link phase of a project's compilation.
My question is, what do I need to do to add loader commands for publicized types that are not supported (apparently) by ld?
In particular, I would like to take advantage of the LC_DYLD_ENVIRONMENT loader commmand, which can be used to specify a string in the loader commands table of a binary that should be loaded and evaluated as environment variable settings in the context of the executable.
I don't see any argument to ld that would facilitate this. Something like "-sectcreate" but for specifically adding to the content of the loader commands, is what I'm after.
I know this is possible because at least one standard app on Mac OS X uses it: Safari. But I don't know whether they achieve this by some kind of post-link massage of the binary, if they're using a custom version of ld that knows how to build and chain the custom loader command in, or if they are exploiting a general-purpopse feature of the ld command that I haven't been able to figure out.
It looks like you can use -dyld_env, like so: "-dyld_env DYLD_FRAMEWORK_PATH=/". This isn't documented in the man page, but can be found in ld64's Options.cpp and mentioned in the Changelog file. If you're trying to do it from Xcode, you'll probably have to do it like this: "-Xlinker -dyld_env -Xlinker DYLD_FRAMEWORK_PATH=/".
One thing to note: if you look at dyld's dyld.cpp, you'll see that it only allows environment variables that start with DYLD_ and ends with _PATH.
If your executable is structured as part of a standard OS X application bundle (i.e. a .app that can be launched by a user), the conventional way to specify application specific environment variables is through its plist file using the LSEnvironment key. See here for more information.
I have to create (or rather modify) software package for MacOSX on Windows. I can do what I need with .pax files, so the only thing left is bill-of-material.
Does anyone know of a library that can do it? Is there BOM file format (Apple-version) available?
TIA
There is now an open source version of mkbom which also compiles for windows at:
http://hogliux.github.io/bomutils/
The windows version still contains some bugs (no special characters in file names and limitations on file path length). However, it should work for simple installers.
The website also has an easy to follow step-by-step tutorial on how to create a Mac OS X installer (however, the tutorial is for linux, see http://hogliux.github.io/bomutils/tutorial.html ).
Well, BOM is not necessary, MacOSX package is a simple directory structure with optional elements, BOM being one of them.