I am trying to compile an app that uses multiple libraries using Xcode. To do so, I created a script that copies all of my .dylibs from a location on my computer to the Frameworks folder inside my app bundle.
After adding the necessary linker flags and header search paths, I must now add my library search paths.
Since I have copied all the libraries inside my Frameworks folder of my app bundle, I have deduced that I must add $(FRAMEWORKS_FOLDER_PATH) to the library search paths setting. Adding this fails, because the linker can not find that directory.
I am guessing that the Frameworks folder isn't created until after searching the library search paths setting. If so, how am I supposed to use the libraries that I have copied inside my app bundle?
Placing the .dylib files in the Frameworks folder is something you do so that the application can find them when it runs.. dylib files are dynamically linked, so the application loads them at run time.
Setting Xcode up to link to the .dylibs at compile time should just be a matter of dragging the .dylib from the Finder into your Xcode project. I've shown this with a simple example project that uses libxar.dylib in the attached screenshot.
Related
I am packing my macOS application into an application bundle. I need to codesign it and pass notarisation. It is possible to put the frameworks in the "Resources" directory?
I have two frameworks. Normally, I used to put such frameworks into the "Frameworks" directory of the bundle. However, for (stupid) designing reason I need to have some more libraries in the same directory of my frameworks. Since such libraries will prevent code signing if placed in the directory "Frameworks", I want to move frameworks + extra libraries into the "Resources" directory.
Reading Apple documentation it seems that frameworks should - of course - belong to the "Frameworks" directory, however I could not find any reference to what should NOT be included into the "Resources" directory. Is this bad practice? Would my .app structure not pass gatekeeper?
Any suggestion would be very much appreciated
You've probably already tried putting a frameworks in Resources by now. As you said, even if it works today, this is not a good idea.
You might be able to work around whatever issue caused you to want to do this by using the install_name_tool to change one of the paths built into your frameworks. Adding symbolic links are another handy device for issues like this. This kind of stuff can be done automatically in a Run Script Build Phase or a Build Phase Post Action.
I need to create symlinks in frameworks inside an app on OSX (vers 10.10.1). I am outside of XCode as the app is developed in Qt. It provides the frameworks, but they need some retouches to work on the new codesigning rules.
I call "ln -s path_origin path_target_link" and apparently it works, the links are created and they resolve to the right place.
But when I codesign the app, I get an error "unsealed contents present in the root directory of an embedded framework"
(In order to verify my procedure, I copied a framework from another package downloaded that validates codesigning and I could sign it successfully, when I create a symlink my way codesign starts to give the error so I'm assuming the problem is my symlink creation)
I tried other methods with the same result so I must be missing something. Any ideas?
For the case it's useful to anyone. In my case the problem was that I was creating the links with absoulte paths. Obviously they should be relative: You move to the directory where the link should go and create the link relative to the current location.
Version 1 code sign recorded only files in the Resources directory and ignored the rest. But version 2 records substantially all files by default. So we have to sign each and every frameworks bundle's versions and app binaries.
Ensure your framework bundle structure is meet the requirement of apple.
According to Apple's documentation, framework bundles don't have a 'Contents' folder. Instead, each version folder gets a 'Resources' folder which contains the Info.plist file, and which is also symbolic linked at the top-level framework folder. Qt5 frameworks have incorrect layout after SDK build, so this isn't just a problem with macdeployqt, but whole framework assembly part.
so confirm, there is no faulty layout in your app bundle.
If you have a *.prl in your Qt framework bundle (i.e.QtCore.framework/QtCore.prl). *.prl file may cause trouble for you as codesign just bails out with "unsealed content presents in the root directory of an embedded framework" without telling exactly what's going on. Strip if you have any prl files.
It is necessary for the Info.plist to have the correct CFBundleExecutable field. At the moment it doesn't. The debug version of Info.plist would overwrite the release version, and it also happens to contain invalid data. In particular, CFBundleExecutable would contain the _debug suffixed library name, which it shouldn't. If you have this problem then modify the incorrect info.plist.
The last step is you have to codesign all the frameworks before you sign the entire app bundle.
For anyone confused about this issue, you can refer to Apple's documentation https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle
It contains all the details for macOS/iOS/MacCatalyst/watchOS/tvOS...
I don't fully understand when to use a workspace.
Here is what I have been doing so far --> Whenever I need to use a static library of another project, I drag the .xcodeproj file from finder to the Xcode navigator of my new project, link the libraries, add the user paths, and start working. I also add the appropriate target dependencies.
Why is using a workspace better? Should I be using a workspace? I have tried understanding apple's documentation, but I seem to be getting whatever I need without explicitly creating a workspace.
Here's what I found so far, it makes using static libraries easier. If you add the path to the static libraries xcodeproj file in your source tree, and specify the path in the build settings user header paths, and set Always search header paths to "YES". Then you're set. All you need to do is link to the static library in your build phase. Code completion works.
I have a directory of source files (.h and .m) that are shared between multiple projects. I'm not building them as a static library; instead, I just include the source in each project.
Previously, I was copying the source into each project independently, but now, I'd like to move to having a single directory that has all of those shared files it, and include a folder reference to them in each XCode project that uses them.
Including them as a folder reference (blue folder) is no problem, and I can add the path to the header includes so that the files in the project can see them. But they're not being built, and thus I'm getting link errors.
How do I get Xcode to build the source in the external directory?
folder references don't work like that in xcode.
this is exactly what an external target (e.g. static library) is for... seems strange that you would choose to duplicate (a portion of) the maintenance for every project. with a library, you can also reduce the build and indexing times (assuming the build settings match some of the time).
if you insist that a static library is a bad idea... you can approximate what you want by creating a custom build script phase for your target (you will need to configure a script, rather than passing the xcode folder reference as input).
I've created a working Cocoa framework which I wish to redistribute. The problem is however, it won't run outside of Xcode. I've read something about #executable_path/../Frameworks, which I did not include, because I don't know where to put it :/
Therefore I run my app in Xcode using the DYLD_FRAMEWORK_PATH variable which works fine, but only in Xcode - if I try to run it on its own it crashes straight away and says IMAGE NOT FOUND.
I'm sure #executable_path/../Frameworks is what's missing, but I don't know where to put it.
Could anyone help me out please? :)
Thanks
Here is how I usually manage things:
In the framework's Xcode project, set the Installation Directory to #rpath
Add the framework to your application's Xcode project. Add a Copy Files build phase, select Frameworks in the Destination popup, and ensure your framework is added so it will be copied to your application's Frameworks directory when it is built.
Finally, in your project's settings, add #loader_path/../Frameworks to Runpath Search Paths.
Are you actually copying the framework into your applications bundle? Look for the folder called MacOS which is what contains the binary. There should be another folder at the same level called Frameworks and it should have the framework inside it.
If it's not there you need to create a copy files build phase for the application that copies the framework into the Frameworks folder.