Outside forum question about statically linking the runtime?

[MikkoM]

I ran into a following kind of problem description and suggestion after doing the recruitment posts, and since the author of this suggestion/problem wasn`t too willing to register to the forums of the project, but still seemed to be very sure of his case, I promised to bring his suggestion here.

Fails to get past the generating stars and AI screen. Appears to be a deadlock, as the processor utilization is near zero, and no harddrive activity is observed. Ran it under BOCHS 2.4.2

Update -
I traced the problem to the fact that you are not statically linking the runtime, which is fine for in house development, but a 'very bad thing' for deployment as it requires the end user to have the exact version of the runtime you used installed on their system. Also, using it for in house development will create mysterious bugs once you decide to switch over to the static libraries. So ultimately it is best to either include the installer for the runtime you use with the package, or to use the static libraries from the start.

...

In THEORY using the DLL version of the runtime lets you update it by simpy installign the latest runtime, except your application specificalyl targets version 7.1, which is from what, windows 98? And by targettign a specific version you cannot take advantage of updated versions, which will use a different version and file names. If your application was capable of using the newer runtimes, it woudl have found the version 9 runtimes I DO have installed on my system. Hence, there is no benefit t be gained from using the DLL's. Although reading your forum I see that this opinion was voiced and got shouted down. Majority rules doesn't work with applications programming. I also notice that many other people are having the exact same problem, all related to the runtime, and yet you have not addressed the issue by making a simple change in the configuration? I highly doubt your team is responsive enough that my 1 extra post would make a difference if the hundreds of posts they have received already have not convinced them to take effective action.

The full discussion can be found here (but as far as I can tell all the necessary info is already quoted above):

http://cboard.cprogramming.com/projects ... post906955

I also wasn`t sure where exactly I should post this.

[OndrejR]

It is open bug.

[Geoff the Medio]

The poster claims there's a way to build the executables with Visual C++ that will not depend on the runtime library version. I've posted on the thread to ask for more information about this.

However the cause of the problem is most likely older dependencies that are already built as DLLs that depend on specific versions of the Visual C++ runtime library. I don't think any linker settings will retroactively fix this... but I'm no linking expert.