What the heck is a library?

A library) is a group of Swift elements that different purposes can use.

Think about that you’re making a easy software to pluralize a string. It really works nice, you end the app and also you begin working in your subsequent one. In your subsequent software, you face the very same subject, you need to print countable gadgets (e.g 2 bananas). What would you do? 🤔

The very first thing that may cross your thoughts is to repeat all of the supply code from the primary software into the second. Nicely, this might work in fact, however what occurs in the event you uncover a bug within the pluralization element? Now you need to repair the difficulty at two locations, since you have simply duplicated your complete stuff. There have to be a greater method… 🧠

Thankfully laptop programmers confronted the very same subject, in order that they invented shared libraries. A shared library is a particular type of binary element that you should use in your most important software. This manner you possibly can outsource Swift code right into a separate file (or bunch of information), throw in some entry management to permit different apps to make use of public strategies and name features out of your library and right here we go, we simply shared our widespread code between our purposes.

Oh wait, there’s a bug within the lib, how can I repair it? Nicely, that is the place issues get a bit sophisticated, however don’t be concerned an excessive amount of, I will attempt to clarify the way it works. So, final time, , once we talked in regards to the Swift compiler and linker, I discussed, that they will resolve dependencies in your program. Whenever you use a library you possibly can select between two approaches.

• static linking
• dynamic linking

Static linking implies that the supply code contained in the library will likely be actually copy-pasted into your software binary. Dynamic linking then again implies that your library dependencies will likely be resolved at runtime. By the way in which, you need to resolve this upfront, since you need to construct both a static or a dynamic library. Huhh? Okay, let me do this once more… 🙃

The static library strategy is extra easy. You’ll be able to simply construct a static library utilizing the compiler (you may see how one can make one afterward), then you possibly can import this library inside your software supply (import MyLibrary). Now whenever you compile the principle app, you need to inform the compiler the placement of your static (binary) library, and the publicly accessible objects (headers or module map) which are obtainable to make use of. This manner when your app consists the symbols from the lib (lessons, strategies, and so on) might be copied to the principle executable file). Whenever you run the app, required objects will likely be there already contained in the binary file, so you possibly can run it as it’s.

The principle distinction between a static and a dynamic library is that you do not copy each required image to the executable software binary whenever you use a dylib file, however a few of the “undefined” symbols will likely be resolved at runtime. First you need to construct your library as a dynamic dependency utilizing the Swift compiler, this can produce a dynamic (binary) library file and a module map (header information). Whenever you make the ultimate model of your app, the system will put references of the dynamic library to your executable as an alternative of copying the contents of the dylib file. If you wish to run your software you need to guarantee that the referenced dynamic library is out there to make use of. The working system will attempt to load the generated dylib file so the appliance resolves the symbols based mostly on the reference pointers. 👈

Ought to I select dynamic or static linking?

Nicely, it depends upon the atmosphere. For instance the Swift Package deal Supervisor prefers to make use of static linking, however Xcode will attempt to construct SPM packages as dynamic dependencies. It’s also possible to explicitly inform SPM to construct a static or dynamic library, however in a lot of the circumstances it’s best to persist with the automated worth, so the system can construct the best module dependency for you.

import PackageDescription

let package deal = Package deal(
    title: "MyLibrary",
    merchandise: [
        
        .library(name: "MyLibrary", targets: ["MyLibrary"]),
        
    ],
    targets: [
        .target(name: "MyLibrary", dependencies: []),
    ]
)

By the way in which in case you are confused sufficient, I’ve an article for freshmen about Swift packages, modules, frameworks and the instruments that makes this complete dependency administration doable. You must positively have a look, it is a some form of a deep dive into FAT frameworks, however the first a part of the article is stuffed with helpful definitions and introductions to varied instructions.

Again to the unique query: static vs dynamic? Do you bear in mind the bug within the library that we have now to repair? In the event you use a static library you need to rebuild all of the apps which are relying on it (they have to be linked with the fastened library in fact) with the intention to make the difficulty disappear. 🐛

Since a dynamic library is loaded at runtime and the symbols aren’t embedded into the appliance binary, you possibly can merely construct a brand new dylib file and exchange the previous one to repair the bug. This manner all of the apps which are referencing to this dependency could have the repair at no cost. There isn’t any have to recompile everyting, besides the defective code within the framework itself. 💪

It is usually price to say that the ultimate app measurement is smaller whenever you use a dylib.

Okay, however why ought to I ever use static linking if dylibz are so cool? The reality is that typically you need to encapsulate the whole lot right into a single binary, as an alternative of putting in a lot of different dylib information into the system. Additionally what occurs if one thing deletes a dylib that your app would require to work flawlessly? That’d suck for certain, particularly if it’s a mission-critical script on a server… 😳

Hopefully, I over-explained issues, so we will begin constructing our very first static library.

Compiling a static Swift library

Do you continue to have that little Level struct from the earlier tutorial? Let’s construct a static library from that file, however earlier than we accomplish that, we have now to explicitly mark it as public, plus we want a public init technique so as to have the ability to create a Level struct from our software. You already know, in Swift, entry management permits us, programmers, to cover particular elements of a library from different builders.

public struct Level {
    public let x: Int
    public let y: Int

    public init(x: Int, y: Int) {
        self.x = x
        self.y = y
    }
}

Now we’re able to construct our static library based mostly on this single level.swift supply file. As I discussed this earlier than, we want a binary file and a module map file that comprises the publicly accessible interface for the lib. You need to use the -emit-library flat to inform the Swift compiler that we want a binary library file plus utilizing the -emit-module parameter will produce a Swift module data file with all of the API and docs wanted for different modules. By default the compiler would emit a dylib (on macOS not less than), so we have now to make use of the -static flat to explicitly generate a static dependency. 🔨

swiftc level.swift -emit-module -emit-library -static

The command above ought to produce 4 new information:

• libpoint.a – The binary static library itself
• level.swiftdoc – Documentation for the module (binary format)
• level.swiftmodule – Information in regards to the module, “Swift header file”
• level.swiftsourceinfo – Supply info file

Transfer these information inside a lib folder, so it’s going to be simpler to work with them. That is actually it, we have simply created a working static library, however how can we use it to hyperlink them towards our most important software? 🤔

Initially, we have now to import our newly created module contained in the most important.swift file if we need to use the objects (in our case the Level struct) from it. By the way in which you possibly can add a customized module title to your library in the event you use the -module-name [name] argument with the earlier swiftc command.

import level

let p = Level(x: 4, y: 20)

print("Whats up library!", p.x, p.y)

So, all of our library information are positioned in a lib folder, and our default module title is level (based mostly on our single enter file). We will use the swiftc command once more, to compile the principle file, this time we use the -L flag so as to add a library search path, so the compiler can find our binary libpoint.a file. We additionally must set a search path for imports, the -I property will assist us, this manner the general public API (headers) of the module will likely be obtainable in our supply file. The very very last thing that we have now to append to the tip of the command is the -l[name] flag, this specifies the library title we wish to hyperlink towards. Watch out, there isn’t a area in between the -l and the title worth! ⚠️

swiftc most important.swift -L ./lib/ -I ./lib/ -lpoint

# run the app
./most important
# Whats up library! 4 20

Voilá, we have simply separated a file from the principle software through the use of a static dependency. 👏

Compiling a dynamic Swift library

In concept, we will use the identical code and construct a dynamic library from the level.swift file and compile our most important.swift file utilizing that shared framework. We simply drop the -static flag first.

swiftc level.swift -emit-module -emit-library

This time the output is barely completely different. We have a libpoint.dylib binary as an alternative of the libpoint.a, however all the opposite information look similar. Extension my range per working system:

• macOS – static: .a, dynamic: .dylib
• Linux – static: .so, dynamic: .dylib
• Home windows – static: .lib, dynamic: .dll

So we have now our dylib file, however the true query is: can we construct the principle.swift file with it?

swiftc most important.swift -L ./lib/ -I ./lib/ -lpoint

# run the app
./most important
# Whats up library! 4 20

Now rename the libpoint.dylib file into libpoint.foo and run the principle app once more.

./most important

# dyld: Library not loaded: libpoint.dylib
#   Referenced from: /Customers/tib/./most important
#   Cause: picture not discovered
# zsh: abort      ./most important

Whoops, looks as if we have now an issue. Don’t fret, that is the anticipated output, since we renamed the dynamic library and the appliance cannot discover it. When the loader tries to get the referenced symbols from the file it appears to be like up dynamic libraries at a number of completely different locations.

• The listing you specified by means of the -L flag (./lib/).
• The listing the place your executable file is (./)
• The /usr/lib/ or the /usr/native/lib/ directories

Because the /usr/lib/ listing is protected by the well-known SIP “guard”, it’s best to ship your dylib information subsequent to your executable binary, or alternatively you possibly can set up them underneath the /usr/native/lib/ folder. Sadly, this lookup technique can result in all form of points, I actually do not need to get into the small print this time, however it could possibly result in compatibility and safety points. 🤫

The excellent news is that now in the event you change one thing within the dylib, and also you merely rebuild & exchange the file then you definitely run the ./most important once more (with out recompiling), the altered dynamic library will likely be used. Simply attempt to put a print assertion into the init technique of the Level struct…

Abstract

Truthfully, I would quite go along with a static library in a lot of the circumstances as a result of utilizing a static library will assure that your software has each obligatory dependency embedded into the binary file.

After all dynamic libraries are nice in case you are the writer of a generally used framework, such the Swift commonplace library, Basis or UIKit. These modules are shipped as shared libraries, as a result of they’re big and nearly each single app imports them. Simply give it some thought, if we might hyperlink these three frameworks statically that’d add quite a bit to the dimensions of our apps, plus it would be method tougher to repair system-wide bugs. That is the rationale why these packages are shipped as shared libz, plus Apple can provides us a promise that these elements will all the time be obtainable as a part of the working system. 😅

In any case, there are some instruments that you should use to change library loader paths, I will inform you extra about this subsequent time. It is going to be a extra superior matter together with completely different languages. I will present you how one can construct a library utilizing C and how one can name it utilizing Swift, with out SPM. 🤓