I think you could probably hack around it a bit to link the dynamic version of this library, as long as in the end you copied it along as well as your final binary, but that's definitely less than ideal.
Since then I've actually been wondering if we could just change it to be static all the time instead, since I'm not entirely sure I see the purpose of it being dynamic (aside from slightly reducing disk usage on macOS). You being forced to use a compatible version of Swift + this library doesn't always seem useful to me, and while theoretically newer versions of Swift might not be fully supported by older versions of the library (I assume?), we've been shipping a vendored old version of the library for a while (to avoid the general issue you're hitting) and haven't hit any of these incompatibilities. But I'd love to hear from some folks on what the original trade-offs were for making that decision.
i ended up just recreating the directory structure of the swift installation in the deployment target in my dockerfile, which worked, surprisingly.
i agree. i don’t understand why i cannot build a SwiftSyntax module that understands a different version of Swift than the one that compiled the parser itself. those two things shouldn’t be connected…