The reality is that those "minor" platforms you refer to are ones where a lot of big iron and expensive systems are. While Go / LLVM will eventually be supported on them, Go is still a very large dependency, and is currently not suitable for OS systems programming.
If you did choose to write a new security library in Go, and supposing that the shared library issue was addressed, you'd still have to severely constrain the design of the library to ensure maximum interoperability.
I'm just not sure it's worth the compromise.
Rust, if it was ready, and its runtime dependencies were also better supported, would be far more appropriate than Go.
What big iron targets would you say are also required? Here are some possibilities I can think of: SPARC, IBM's z/Architecture (what about ESA/390 or earlier?) and POWER (the latter of which historically includes more than one ISA), Intel's IA-64 (Itanium, used by HP).
Modulo the various Power ISAs, which I am not familiar with, LLVM claims "is generally reliable" support for all of the about except IA-64: http://llvm.org/docs/CodeGenerator.html#target-feature-matri...
Which doesn't mean production level quality, of course.
More critically, just because LLVM has back end support of an architecture, doesn't mean any particular language using LLVM will support it, or at least as I recall, the language has to know and use details about the back ends it's targeting.
Regardless, one of LLVM's biggest problems internally is the number of unaligned accesses, which hurts its performance on many architectures (except x86 of course, where the penalty is very minor). That's not specific to SPARC, but it does hurt performance there quite a bit as well as cause other problems.
That would be pretty awful; on how many architectures do they still cause exceptions?
ARM says the ARMv6 was the first architecture to support this (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....).
They're worked around by forcing alignment at the cost of performance if I remember correctly, or in some cases, they're not and cause LLVM to fail.
The alignment problems may be unique to the SPARC backend of LLVM, but I don't recall the specifics.
As for Go's large dependencies are you talking about the Go runtime as build time dependency, because Go is notable for its pronounced lack of runtime dependencies?
In any case, I think you and I both have an understanding of the issues at hand, I just think we would be willing to make different trade-offs.