In Craft, to create a package, we can use craft --package <blueprint-name> after the compiling and the installing of a library or an application with given blueprint name.
On macOS, MacDMGPackager is the packager used by Craft. The MacDylibBundleris used in MacDMGPackager to handle the dependencies.
In this article, I’ll give a brief introduction of the two classes and the improvement which I’ve done for my GSoC project.
MacDMGPackager
MacDMGPackager is a subclass of CollectionPackagerBase. Its most important method is createPackage.
First of all,
1 | self.internalCreatePackage(seperateSymbolFiles=packageSymbols) |
Initialisation of directory variables
Here we get the definitions, the path of the application which we want to pack, and the path of archive.
The appPath should be the root of an application package with .app extension name. According to the convention of applications on macOS, targetLibdir points to the library directory of the application.
During the compiling and the installing period, in the application directory, there is only a .plist and MacOS subdirectory. So next, the library directory is created for further using.
1 | defines = self.setDefaults(self.defines) |
Moving files to correct directories
Then, we predefine a list of pairs of source and destination for directories and move the files to the destinations. The destionations are the correct directories of libraries, plugins and resources in a macOS application package.
1 | moveTargets = [ |
Fixing dependencies using MacDylibBundler
After the moving, we create an instance of MacDylibBundler with appPath. After the with instruction, all the codes are executed with DYLD_FALLBACK_LIBRARY_PATH=<package.app>/Contents/Frameworks:<Craft-Root>/lib environment variable.
For further reading of this environment variable, please refer this question on StackOverFlow.
1 | dylibbundler = MacDylibBundler(appPath) |
Fixing dependencies of main binary
Here, we firstly create an object of Path. It points to the executable of macOS Package.
It should be reminded that, although here, we use the same name for both the macOS application package and the executable, it is not mandatory. The name of executable is defined by CFBundleExecutable in the .plist file. So maybe read it from the .plist file is a better solution.
Then, the method bundleLibraryDependencies is used to copy libraries and fix dependencies for the executable in the package.
A brief introduction of this method:
- Call
utils.getLibraryDepsfor getting a list of dependencies. This operation is done by usingotool -L. - Copy missing dependencies into
Contents/Frameworks, and update the library information in the executable.
I’ll give an analyse in detail in the next chapter.
1 | CraftCore.log.info("Bundling main binary dependencies...") |
Fixing dependencies in Frameworks and PlugIns
And then, we try to fix all the dependencies of libraries in Contents/Frameworks and Contents/PlugIns.
1 | # Fix up the library dependencies of files in Contents/Frameworks/ |
Fixing dependencies using macdeployqt
The macdeployqt is used to fix the Qt libraries used by the application. Craft installed it while compiling and installing Qt. But don’t worry, it is not in your system path.
I have not yet found what macdeployqt exactly do, it’s nice to have an look at its source code.
1 | if not utils.system(["macdeployqt", appPath, "-always-overwrite", "-verbose=1"]): |
Removing files in blacklist
If macdeplyqt added some files which we don’t want, they would be removed here.
1 | # macdeployqt might just have added some explicitly blacklisted files |
Fixing dependencies after fixing of macdeployqt
After macdeplotqt, there may be some libraries or plugins added by macdeplotqt. So we do the fixing of dependencies once again.
But I’m doubting if we need to fix twice the dependencies. I’ll update this post after I figure out what will it lead to if we fust fix after macdeployqt.
1 | # macdeployqt adds some more plugins so we fix the plugins after calling macdeployqt |
Checking dependencies
Then, we use MacDylibBundler to check all dependencies in the application package. If there is any bad dependency, the package process will fail.
1 | # Finally sanity check that we don't depend on absolute paths from the builder |
Creating DMG image
Up to now, everything is well, we can create a DMG image for the application.
1 | name = self.binaryArchiveName(fileType="", includeRevision=True) |
An example of DMG image is like this one, users can drag the application into Applications directory to install it.
MacDylibBundler
Constructor
1 | def __init__(self, appPath: str): |
In the constructor, a set is created to store the libraries which have been already checked. And the appPath passed by developer is stored.
Methods
This method bundleLibraryDependencies and _addLibToAppImage are the most important methods in this class. But they’re too long. So I’ll only give some brief introduction of them.
_addLibToAppImage checks whether a library is already in the Contents/Frameworks. If the library doesn’t exist, it copies it into the diretory and tries to fix it with some relative path.
1 | def _addLibToAppImage(self, libPath: Path) -> bool: |
bundleLibraryDependencies checks the dependencies of fileToFix. If there are some dependencies with absolute path, it copies the dependencies into Contents/Frameworks by calling _addLibToAppImage. And then, it calls _updateLibraryReference to update the reference of library.
1 | def bundleLibraryDependencies(self, fileToFix: Path) -> bool: |
As description in the docstring, fixupAndBundleLibsRecursively can remove absolute references and budle all depedencies for all dylibs.
It traverses the directory, and for each file which is not symbol link, checks whether it ends with “.so” or “.dylib”, or there is “.so.” in the file name, or there is “.framework” in the full path and it’s a macOS binary. If it’s that case, call bundleLibraryDependencies method to bundle it in to .app package.
1 | def fixupAndBundleLibsRecursively(self, subdir: str): |
areLibraryDepsOkay can detect all the dependencies. If the library is not in @rpath, @executable_path or system library path, the dependencies cannot be satisfied on every mac. It may work relevant to the environment. But it will be a big problem.
1 | def areLibraryDepsOkay(self, fullPath: Path): |
Here, in checkLibraryDepsRecursively, we traverse the directory to check all the dependencies of libraries, which is .dylib or .so.
1 | def checkLibraryDepsRecursively(self, subdir: str): |
Static methods in class
The _updateLibraryReference method can use install_name_tool -change command to change a reference of dynamic library in a macOS/BSD binary.
1 |
|
The _getLibraryNameId method can use otool -D to get the identity of a dynamic library in a macOS/BSD binary.
1 |
|
The _fixupLibraryId method can use install_name_tool -id to try to fix the absolute identity of a dynamic library in a macOS/BSD binary.
1 |
|
Conclusion
This class is a magic class which can achieve almost everything on macOS.
But the code style is a little confusing. And the parameters are not agreed. Some methods use str to represent a path, some use Path.
Maybe this can be also improved in the future.
Anyway, it’s really a helpful class.
Improvement
During my bonding period, I found that there is a library named qca-qt5 is not fixed appropriately. It caused a crash.
Locating the problem
After analyzing of crash log, I found that the library qca-qt5 is loaded twice. Two libraries with same dynamic library id caused this crash.1
2qca-qt5 (0) <14AD33D7-196F-32BB-91B6-598FA39EEF20> /Volumes/*/kdeconnect-indicator.app/Contents/Frameworks/qca-qt5
(??? - ???) <14AD33D7-196F-32BB-91B6-598FA39EEF20> /Users/USER/*/qca-qt5.framework/Versions/2.2.0/qca-qt5
One is in the .app package, the other is in CraftRoot/lib.
As far as I know, qca-qt5 tried to search its plugins in some path. The one in the package is not fixed, so it started a searching of plugins in the CraftRoot/lib directory. The plugins in it refer the qca-qt5 in the directory. So the two libraries with the same name are loaded, and the application crashed.
Cause
With good knowing of MacDylibBundler, we can improve it to fix the bug. And this will be helpful to other applications or libraries in Craft.
I noticed that all the libraries with .dylib can be handled correctly. The problem is based on the libraries in the .framework package. It seems that Craft cannot handle the dynamic libraries in the .framework correctly.
And we can see that, in checkLibraryDepsRecursively, only .so and .dylib are checked. So this is a bug covered deeply.
1 | CRAFT: ➜ MacOS otool -L kdeconnectd |
In the _addLibToAppImage method, the library in the framework is copied directly to the Contents/Frameworks. For example, lib/qca-qt5.framework/Versions/2.2.0/qca-qt5 becomes Contents/Frameworks/qca-qt5.
And then, during the fix in fixupAndBundleLibsRecursively method, according to the following code, it will not be fixed. Although it should be in a .framework directory and it’s a binary, after _addLibToAppImage, it will not be in a .framework directory. So it will not be fixed.1
2
3
4
5
6
7if (filename.endswith(".so")
or filename.endswith(".dylib")
or ".so." in filename
or (f"{fullpath.name}.framework" in str(fullpath) and utils.isBinary(str(fullpath)))):
if not self.bundleLibraryDependencies(fullpath):
CraftCore.log.info("Failed to bundle dependencies for '%s'", os.path.join(dirpath, filename))
return False
Fixing it !
To fix it, I think a good idea is copying all the .framework directory and keeping its structure.
I firstly do a checking in the _addLibToAppImage method. For example, if qca-qt5 is in the qca-qt5.framework subdirectory, we change the libBasename to qca-qt5.framework/Versions/2.2.0/qca-qt5. So the targetPath can also be updated correctly.
1 | libBasename = libPath.name |
After several checkings, an important section is copying the library. I add some code to check if the library is in a .framework directory. If a library is in a .framework directory, I try to copy the entire directory to the Contents/Frameworks. So for qca-qt5, it should be Contents/Frameworks/qca-qt5.framework/Versions/2.2.0/qca-qt5.
1 | if not targetPath.exists(): |
After copying, another important point is in _updateLibraryReference. If a library is in a .framework directory, the new reference should be @executable_path/../Frameworks/*.framework/....
1 | if newRef is None: |
After fixing, the executable can be launched without crash.
1 | CRAFT: ➜ MacOS otool -L kdeconnectd |
Conclusion
In the software development, there are always some cases which we cannot consider. Open Source gives us the possibility of collecting intelligence from people all over the world to handle such cases.
That’s also why I like Open Source so much.
Today is the first day of coding period, I hope all goes well for the community and all GSoC students :)