You know, this is a really short chapter.
And it’s the last chapter of Part II.
And the last five posts have taken multiple days to write, and have all come out far too long for any human to reasonably read.
And the mess that was cross-compilation left me kind of drained, and not very excited to keep reading.
So I’m gonna take it easy this time.
The only platform mentioned here is Darwin. Which happens to be my platform. So I hope to learn a thing or two.
Okay, we use
clang here, not
gcc. And it’s great, by the way. The first time I saw an error message from
clang… truly eye-opening. I feel like the bar for acceptable compiler error messages is a lot higher than it was ten years ago. How much of that is thanks to
clang? I do not know.
On Darwin, libraries are linked using absolute paths, libraries are resolved by their
install_nameat link time.
I realize I am grammatically pretty picky but this is really a case where a semicolon would improve the legibility of that sentence. I had to read it a couple times.
Sometimes packages won’t set this correctly causing the library lookups to fail at runtime. This can be fixed by adding extra linker flags or by running
install_name_tool -idduring the
I don’t know what
install_name is. I google it, and am sort of confused. It seems that it’s a property of a
.dylib file? That tells you how to refer to said file? But… if you are looking at the
.dylib file… you must have referred to it already. It seems to also be a format for specifying paths to
.dylibs relative to
RPATH or the current executable or whatever. But that doesn’t seem to be the usage here.
Hmm. I guess this is… some sort of safety precaution? That you can only refer to the
.dylib in the precise way that the
.dylib wants you to refer to it? No; that’s insane. I have no idea what this is. I will learn more if I ever have to.
There’s another weird note about dynamic linking, where tests might fail because the
checkPhase is run before the
installPhase – the implication being that the
installPhase sets the
install_name. So I can either run tests after install or set
Lastly, anything that uses
xcrun in its build steps need to actually use
cc directly. Or if it actually uses a
.xcodeproj, use the
$ sd nix info xcbuild xcodebuild-0.1.2-pre Xcode-compatible build tool
Neat. Alright. That’s it!
We’re done. A short chapter, to cap off a very long “part.” And the first bite-sized blog post in three weeks. Feels good, you know?
- Why is
install_namean intrinsic property of a