I have some binaries (executables plus some dynamic libraries) which I want to include as part of the application bundle. How do I go about adding those to xcode such as they are all properly signed when archived?
You can put your binaries wherever you want in your bundle. Just create a "Copy files" build phase in your target. And than you must sign this binaries separately, before signing the main bundle.
You can also create the "Run script" phase and sign your binaries inside this phase.
codesign -s "authority" "${TARGET_BUILD_DIR}/path/to/your/lib.dylib"
Related
I have an app that has jvm built in.
I tried to upload it to apple for notarization, but I was getting the binary is not signed errors
severity "error"
code null
path "Myapp.dmg/Myapp.app/Contents/Resources/javafx-media-11-mac.jar/libfxplugins.dylib"
message "The binary is not signed."
docUrl null
architecture "x86_64"
I had already signed Myapp.app and also signed Myapp.dmg with --deep & --options runtime
I also tried signing all files in my app folder with
find Myapp.app -exec codesign -f -s $MYDEVELOPERID --deep --options runtime {} \;, but still didn't work.
Note that the file path I got from the error is inside the jar file.
I already signed the jar file. Do I also need to unpack the jar file and sign every single file and repack it? It would be too trivial!
also signed Myapp.dmg with --deep & --options runtime
It would appear --deep isn't yet coded to traverse inside JAR files.
I already signed the jar file. Do I also need to unpack the jar file and sign every single file and repack it?
Yes. The bundled .dylib, .jnilib (and likely .so's) need to be individually signed. If they're provided by a 3rd party from within a JAR you will need to extract, sign and then re-bundle the JAR file.
In your case, the JavaFX is no longer bundled with the Java 11 Runtime, so it's the JavaFX JAR that you're bundling that you'll need to extract, sign and re-zip.
This process is spelled out (generically) here: https://stackoverflow.com/a/53528020/3196753. There's also a link to an ANT-specific code here but each build will need very specific code so it's only provided as a reference point of a working, notarized build.
For example, in the above ANT example, the PowerPC binaries needed to be stripped out by hand. Many projects still provide PowerPC binaries, but the notarization will fail if they're part of the distribution.
One would think the owness of signing these .dylib files should be on the provider of the JAR but I've found nothing about allowing mixed signers in projects in any of Apple's documentation.
I've put libsteam_api.dylib in the project folder. I've dragged it into the 'frameworks' folder in the project, and added it to the target. It shows up in the list of linked libraries
When I build and run, I get a "Library not loaded" error, and libsteam_api.dylib is nowhere to be found in the application bundle.
If I then manually copy the library into the MacOS folder of the bundle alongside the executable, it runs fine, but I don't want to have to keep doing that for every build
How do I get Xcode to include the library alongside the executable?
Add a Copy Files build phase to your target, copying the dylib into the Frameworks folder of the app package.
Just banged my head against this as well. There are two pieces to the solution.
1) In your project target's General settings, add the dylib to the list of "Frameworks, Libraries, and Embedded Content", then set its option to "Embed & Sign".
2) Then, under Build Phases (where it should now appear in the "Embed Libraries" section), set its destination to "Executables". (Steam's dylib wants to live alongside the executable, not in the Frameworks directory.)
I am new to cocoa and mac development. I have written an application which is combination of objective-c using cocoa framework and backend written in C++ library dylib.
I am using xcode 4.6 and have the above two projects Cocoa app and my C++ library. C++ is also my own project.
Now it is time for deployment. I want to make a pkg installer for it.
I could run/debug it in the xcode 4.6 because I had added search library path in the object-c project settings to be the output directory of the C++ project. Therefore it could find the dependency and run without crash.
Now in the Objective-C project tree inside the xcode I see products -> mysoftware.app file. if I find the location of this mysoftware.app file in the finder and run it, it crashes. I open the package contents of this app files and I see contentsfollowing structure
contents\(info.plist, MacOS, pkginfo, resources )
I do not see my C++ library in there, when I run mysoftware.app directly double clicking it crashes as it can not find the dylib I see the stack trace in the report window it can not find dylib, complaning that library not found usr/local/lib/mylib.dylib
I have also manually put the dylib file in the .app within the MacOS where my executable is, hoping that it will find the lib from the same directory, it did not , gave the same message above and looking from the the sane location /usr/local/lib/mylib.dylib
So my question is how do I resolve dependency of .app package for deployment, should I need to put the dylib inside the .app package ? how do I do that and then my next step would be to put this single .app thing in the pkg installer,
Thanks
This is what worked for me:
Drag the dylib into your Frameworks.
Add a Copy Files build phase, destination Frameworks and put the dylib there.
Add a Run Script phase which has the following script:
MYLIBNAME=libmylib.dylib
install_name_tool -change /usr/local/lib/$MYLIBNAME #executable_path/../Frameworks/$MYLIBNAME "$BUILT_PRODUCTS_DIR/$EXECUTABLE_PATH"
That's it. The script tells your app to load the dylib from the right place - otherwise it will complain about not finding the dylib at runtime.
Note that you don't need to change anything in the dylib itself - it could be supplied from elsewhere.
I resolved it so I am putting up this answer to help others who want to do the same.
The dylib has to go in one of the sub folders within the application bundle (i.e. mysoftware.app). Could be MacOS, Frameworks or any sub folder we decide to put it in.
The first step is in the target settings of our dylib, we set the install path to be relative to the app bundle (mysoftware.app), so in Xcode target settings of lib I set it to:
#executable_path/../frameworks
You can also use #rpath (You might want to research on that, I think it is more flexible than #executable_path)
Xcode will change the install name as well for our dylib.
Then in the Objective-C project using our dylib in the Project settings -> Build phases -> Link -> we drag our dylib here from the products node of the dylib project.
In the Objective-C/Cocoa project, the last step is to add a build step named copy files, and it should show a combo box telling you the target folder of the bundle. I set it to frameworks (this will depend on that relative path you choose when setting install path of your dylib) . The second part of the 'Copy Files' build step is to provide the souce file to copy. That's our dylib file that we want to pack in the bundle's Frameworks folder. So drag the dylib file from the products (of your dylib project) to the source file of the build step.
And that's it.
Now when we build the Objective-C or Cocoa project, if our build steps and install_path , etc are correctly configured, it should build fine. After a successfull build of the Cocoa project, go to Products -> mysoftware.app -> Locate in the Finder and when you run it, it should run fine. Since the dependency dylib is in the Frameworks folder of the bundle and correctly linked. You can see the package contents of the bundle to see if the Frameworks folder contains your dylib file.
To my surprise, the path where a dylib is stored has to be part of the dylib. So when a project links to this dylib it will copy the same path in itself, so when we run the Cocoa app which was linked to that dylib, it will look for it at exactly the same path which it copied from inside the dylib and we are responsible for telling the dylib where it exists. In the form of install_path, etc.
There are tools to manually update the dylib's install path stored in the Cocoa project using that dylib. If update the path of an existing bundle using these tools it should be changed in the client of the dylib, not required in the dylib itself.
If we've the code then we can change it in Xcode as instructed above.
otool -L my.dylib for example can be used to see the dylib install path of an existing binary lib
install_name_tool -change can be used to update the install path of existing binary lib
I have a workspace with an app and a static lib. The lib is used in the project.
When I modify the lib and build the app, the lib is well rebuilt: cool! But if I have not modified the app, the newly built lib is not packaged within the app, it lets the old one. To have the newly built lib, I have to modify the app (I add a space and delete it)...
I have tried both ways: letting Xcode managing dependencies automatically, and explicitly added the lib in the app build phase.
So if someone has an idea!
Thanks in advance.
I dont fully get it I am afraid... you hit 'archive' and the .a file isn't included together with the .app inside the archive?
to get the .a file included in the archive, set:
go to build settings > your static lib > skip install and set it to NO
after the comments:
you HAVE to touch the app to get it copied to the simulator again.. mock editing a file should help
you can maybe automate this too:
add a scripting phase to the lib's build phases and have it run touch %PATH_TO_AN_M_FILE_FROM_THE_APP%
I'd like to include a zip file as an attachment to in app email (OS 3.0). I've added the file to my Xcode project and get this message during building:
Checking Dependencies
warning: skipping file '/Users/account1/Developer/Doc4_5.zip' (unexpected file type 'archive.zip' in Frameworks & Libraries build phase)
Is there something else I need to do or another technique to make this work?
You need to move your ZIP archive from the "Link Binary with Libraries" build phase to the "Copy Bundle Resources" phase. Open up your target with the disclosure triangle, and drag it from one to the other.
I'd guess that it ends up in the Libraries phase as an unexpected side-effect of the Java support built into Xcode.