True, but wouldn't the "build" have to be documented, as to which gcc version (& maybe? which Windows OS version), with which compiler options, built each library.   Then one would still have to "jigger" one's own build environment, i.e. gcc version and options for ones coin's sources to match?  And perhaps the rest of the tools that come along "for the ride", and their OS & whatever else requirements?  Seems like a "tangled web we weave" when we chase the latest and greatest "tool-set".  Or is it my imagination?

And don't linux versions have innate "affinity" to a gcc version.  What if that isn't the one you now need?  Can you have separate "build environments" so that you can have different gcc's on your machine?

The tough one, I'm told, is the Qt libraries so that one can build a "static" Qt coin, and still have Qt designer &/or Qt creator on one's machine, since I believe, though I'm not sure, that they "like" the dynamic Qt libraries?  nitrogenetics, what say you? 

I don't know about gcc forward-backward compatibility and debug-release and static-dynamic nuances as I am a Windows fan, where we have our own peccadilloes about static (/MT-/MTD) dynamic (/MD-/MDd) build options and d and sd .lib & .dll lib suffixes for static-dynamic debug-release versions, and some ABI changes between MSVC++ versions, though not between the two I use:)

That's why I built my (MS & gcc) Windows libraries once and have used them to make many a (static) daemon and (dynamic) Qt version, as demonstrated in my videos.  And those were on a WinXPSP2 machine!!  I use Win 8.1 now in exactly the same way.

Ron