Geoff the Medio

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.

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.

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

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...

abachler

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

__________________
Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

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.

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.

__________________
Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

Mario F.

Yes, you would have to rebuild all dependencies and link them statically to the runtime. In any case, on a good working environment you should always have both (/MD and /MT) builds. Dunno about your coders at FreeOrion, but most people do.

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

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.

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

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?

__________________
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

abachler

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.

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.

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.

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.

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.

__________________
Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

Geoff the Medio

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...

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.

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

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.