Thread: FreeOrion seeks C++ programmers willing to learn.

Originally Posted by abachler

The proper way to fix it is to use teh static libraries, not the DLL's.

It is simple in the extreme to change to the static libraries. It is a single setting in the configuration of the project, although if you have the solution broken into several sub projects it is best to change the configuration at the solution level. All you do is change the runtime setting from Multithreaded DLL to Multithreaded (which is the static library). You have to change ti for every subproject though, which you are obviously not doing or there wouldnt still be a dependancy on the 7.1 libraries.

That would be simple if there were no dependencies... I'm no compliation or linking expert, and do please correct me if I'm mistaken, but would this not linking all the dependencies statically? This would include finding or building statically linkable libraries for several boost library (easy enough to get from boostpro), OGRE (complicated, though mostly already set up), opengl, libpng, glew, openal, zlip, alut, vorbisfile, libexpat, and jpeg.

Anyway, I did some digging with dependency walker, and as far as I can tell, only one of the three FreeOrion executables - the AI client - depends on the version 7.1 visual c++ runtime library. This is consistent with the reported crashes, which are occurring after or during universe generation, which is when the AI clients would be started and attempt load their dependencies. The 7.1 dependency comes from python25.dll (AIs are scripted in Python) which is not something we built, which is why previous efforts to make sure everything was built with the latest version of the visual C++ compiler didn't get rid of this older-version runtime dependence.

In no case am I downloading an older version of the libraries. Sorry, its just not going to happen.

My point was not that you specifically should do this, but rather that it's a relatively easy fix for anyone interested in trying out the program. Not good, but not the worst problem there could be.

If you are having problems with multiple inconsistent dependencies, then I am going to assume that your project is basically spaghetti code at this point.

I don't see how a dependency version issue implies the project's own code is poorly structured, but OK... assume away.

Im not setting up another svn folder on my system, but if you zip or rar the project into a single file and post it fro download ill take a look at it and see what I can fix. Make sure whatever you send me actually compiles and runs though, and I only want the windows version, I coudlnt care less about the linux version.

I appreciate the offer, but we don't use a Visual Studio project to build the windows releases. Rather, a SCons script does the building, and even if you have SCons installed, I'm guessing you don't want to go spelunking into those build scripts. Also, I believe the SCons stuff is being replaced by CMake anyway...

Originally Posted by Geoff the Medio

I appreciate the offer, but we don't use a Visual Studio project to build the windows releases. Rather, a SCons script does the building, and even if you have SCons installed, I'm guessing you don't want to go spelunking into those build scripts. Also, I believe the SCons stuff is being replaced by CMake anyway...

That explains why you are having dependency issues and cannot simply or easily switch to the static libraries.

Originally Posted by abachler

That explains why you are having dependency issues and cannot simply or easily switch to the static libraries.

How so?

The dependency issue comes from linking to an older version of the Python DLL. This has nothing to do with whether the program is built from within the IDE or by calling the compiler and linker from the command line with a script. (The command line script can do anything that can be done in the IDE, which usually even indicates what command line /switch a particular GUI option enables.)

Also, switching to the static runtime libraries would require (so far as I know) switching most dependencies to be statically linked, which would be somewhat complicated (compared to adjusting a single setting in the project configuration) even when building from in the IDE.

Originally Posted by Geoff the Medio

How so?

The dependency issue comes from linking to an older version of the Python DLL. This has nothing to do with whether the program is built from within the IDE or by calling the compiler and linker from the command line with a script. (The command line script can do anything that can be done in the IDE, which usually even indicates what command line /switch a particular GUI option enables.)

Also, switching to the static runtime libraries would require (so far as I know) switching most dependencies to be statically linked, which would be somewhat complicated (compared to adjusting a single setting in the project configuration) even when building from in the IDE.

You cannot easily change to the static libraries because you are not using a compiler that has the option to easily switch. In Visual Studio, changing to the static libraries is as simple as changing a single option in the solution configuration menu. All projects in teh solution can then be changed to use the same version with a single action.

Originally Posted by Mario F.

Still, I disagree with abachler in that I suggest you keep your crt dynamically linked.

Originally Posted by Mario's Link

There are LOTS of reasons for always using the multithreaded DLL:

1) Your application is smaller because it doesn’t have the C runtime library loaded into it.

This is dubious at best, It will be very slightly smaller on disk, by maybe at most a few hundred kilobytes, but it will be larger in memory, since your application has to now have the library loading code as well as the library itself once loaded.

2) Because of #1, your application will load faster. The C runtime library is almost certainly in memory, so the pages containing the library don’t have to be read from disk.

No it won't. In fact it will take longer to load, because rather than having the runtime functions inlined, they now have to be loaded form disk and then linked internally, which takes time.

3) Using the multithreaded DLL future-proofs your application. If you ever add a second thread to your application (or call into an API that creates multiple threads), you don’t have to remember to change your C runtime library. And unless you’re running the app verifier regularly, the only way you’ll find out about the problem is if you get a heap corruption (if you’re lucky).

Ok this is just complete horsepucky. It doesn't future proof anything. If you set static linking you can say the same thing, that you don't have to remember to change the linking.

4) If your application has multiple DLL’s, then you need to be VERY careful about allocation – each DLL will have its own C runtime library heap, as will the application. If you allocate a block in one DLL, you must free it in the same DLL.

Which has absolutely nothing to do with what runtime you use. In fact If you statically link this problem goes away, but if you dynamically link you may end up getting dependency issues when 2 DLL's try to load different runtime DLL's. Statically linking solves this issue as the functions are inlined.

5) If a security bug is ever found in the C runtime library, you don’t have to release an update to your app.

Dubious at best, since for the most part security fixes come out as new functions you have to recompile to use the safe functions anyway.

Originally Posted by abachler

You cannot easily change to the static libraries because you are not using a compiler that has the option to easily switch. In Visual Studio, changing to the static libraries is as simple as changing a single option in the solution configuration menu. All projects in teh solution can then be changed to use the same version with a single action.

Scripts that run the VC++ compiler and linker from the command line can been set up to make this change just as easily. The dependency issues remain in either case...

Originally Posted by Mario F.

Being you, I'd be worried at this time. You, who openly admit not being knowledgeable about these things, seem to have found the problem when your coders have not.

I am programmer / coder for the project, but don't program professionally and have no interest in or knowledge of linker issues or troubleshooting dependency versions and such. Moderate skill and contribution in the former doesn't require much experience in the latter, in practice.

In any case, I'm sure you now understand this was always an easy problem to find the source of and an easy fix.

Indeed, but it being difficult to diagnose and fix wasn't the reason why nobody's bothered yet to do so.

SCons? CMake? Not only you are going from horse to mule but you are completely ignoring the red Ferrari. Why not use Visual Studio own build system? WHat one earth makes you want to use SCons for the Windows build? And, more curious even, what are you folks thinking moving it to CMake? You enjoy pain?

I personally use a Visual Studio solution to code and test build FreeOrion, and I maintain these solution files in the SVN repository. The lead programmer works primarily on Linux and doesn't use the MSVS IDE at all to my knowledge, an instead he builds the Win32 release package executables using SCons. SCons, and in future CMake, let him maintain one set of build files for the project that work on multiple platforms. I gather he finds this preferable to separately maintaining the build setups for each OS. Whatever other reasons various projects have for using cross-platform build tools probably apply as well. Again though, I'm not particularly interested in these issues, so don't know all the details and reasons.