i didn't see it and still can't maybe i am being blind or selectively filtering it without realising... :/

> low level libraries like crash reporters which can not be platform independent.

> Or libraries that rely on platform specifics, like UIKit on iOS.

this is actually not true and i can quite comfortably demonstrate this and have worked in multiple code bases that do such things across all the major platforms, including games consoles...

these pieces are the unavoidable platform dependent bits and can be conditionally compiled accordingly - they are however usually quite small, and also something which a library can not do

this is imo far and way the biggest strength of source code inclusing and precisely what i refer to by 'you can run on every current platform and even ones that don't exist yet'

even 'cross-platform' APIs like OpenGL necessitate this because they make mistakes, or have ES flavour on mobile with breaking changes vs. Desktop OpenGL.

EDIT: "> In the years past, for example, I saw issues related to a specific linker bug that resulted in improper relocation of Mach-O symbols during final linking of the executable, and crashes that thus only occurred in the specific user's application, and could only be reproduced with a specific set of linker input."

ah i guess you mean this. in which case how does a library avoid this? the linker inputs are usually roughly equivalent to libraries... the compiler generated a bad object file consistently? I'll agree that compiler and linker bugs exist but they are the exception and not the case - that effects source code and not the library is indeed an advantage of a pre-compiled library. I consider it vanishingly unimportant against being able to work across /all platforms/.

The issue isn't about "conditional compilation": the issue is about symbol visibility. In fact, I don't think any of the issues discussed in this article--excepting the bug at the end with MH_OBJECT--would be solved by giving someone source code: adding a directory of C files to your project is semantically identical to adding a .a file using -all_load. This is clear and somewhat obvious, as the only thing I did to create a .a file was to compile the .c files to .o files for you, which will be the very first thing your compiler does with the .c file anyway: all I'm doing is saving you CPU time and some hassle, I'm not changing what happens when the code hits the linker, and that's where the problem lies. Let's look at one random specific example from the article (which again, is full of things that happen at link time, and so would be exactly identical whether you started with source code or archive files): PLCrashReporter includes a custom build of sqlite3 that has different options than Apple's; you want the user's code to continue using the version of sqlite3 that comes on iOS, but you want PLCrashReporter and PLCrashReporter only to use the custom build. If I give you a giant wad of course code files, which would then of course include the custom build of sqlite3 with the extra options PLCrashReporter needs turned on, all of that is going to be compiled down to .o files (again, exactly what would be in a .a file that I'd give you were I to have compiled it ahead of time), and the sqlite3 symbols from the included modified copy would then take precedence over the ones that come with Apple's SDK for all files in the project: you solved nothing.