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.

Chapter 10. Platform Notes

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_name at 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 -id during the fixupPhase.

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 DYLD_LIBRARY_PATH. Okay.

Lastly, anything that uses xcrun in its build steps need to actually use cc directly. Or if it actually uses a .xcodeproj, use the xcbuild package:

$ 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_name an intrinsic property of a .dylib file?