Fix Heap Alloction issues in QTFred

[TheForce172]

There have been multiple heap crash issues with QTFred on that have been traced to the fact that QT Distributes its libraries with dynamic linking while we are using static linking. We most likely can't distribute statically linked version of QT due to licencing issues between QT and FSO's licenses. So are only option is to compile dynamically if we are building QTFRED.

[JohnAFernandez]

I don't think anyone else is going to look at this. Hold on to your butts.

[wookieejedi]

Given Cyborg approved and TheE says it looks fine, I'll plan to merge tomorrow.

[Goober5000]

This does look like the best solution, from a design standpoint, but this PR only touches MSVC. We'll need to build QtFRED dynamically regardless of whatever build environment we use or what OS we build on.

[notimaginative]

This does look like the best solution, from a design standpoint, but this PR only touches MSVC. We'll need to build QtFRED dynamically regardless of whatever build environment we use or what OS we build on.

I'm pretty sure this is an issue specific to MSVC (or using that toolchain). So this shouldn't be a problem on other platforms and/or toolchains. I'm not sure whether it applies to cross-compilation though (don't think so?).

[Goober5000]

This does look like the best solution, from a design standpoint, but this PR only touches MSVC. We'll need to build QtFRED dynamically regardless of whatever build environment we use or what OS we build on.

I'm pretty sure this is an issue specific to MSVC (or using that toolchain). So this shouldn't be a problem on other platforms and/or toolchains. I'm not sure whether it applies to cross-compilation though (don't think so?).

But licensing issues would apply regardless of platform. Or do the other platforms already link dynamically?

[notimaginative]

This does look like the best solution, from a design standpoint, but this PR only touches MSVC. We'll need to build QtFRED dynamically regardless of whatever build environment we use or what OS we build on.

I'm pretty sure this is an issue specific to MSVC (or using that toolchain). So this shouldn't be a problem on other platforms and/or toolchains. I'm not sure whether it applies to cross-compilation though (don't think so?).

But licensing issues would apply regardless of platform. Or do the other platforms already link dynamically?

Oh no, this isn't about linking with Qt, it's about how linking is done with the Windows runtime. Qt links the Windows runtime dynamically, while FSO links it statically. And you can't safely mix the two methods. And it's much easier to just change how FSO links than Qt does.

[Goober5000]

Ok, fair enough.

EDIT: A quick search shows that MSVC_USE_RUNTIME_DLL is used in several places across the codebase, including to determine whether MFC itself is linked dynamically. I'm wondering if MSVC_USE_RUNTIME_DLL should be set based on FSO_BUILD_QTFRED, rather than adding this one special case here.