FreeOrion seeks C++ programmers willing to learn.

This is a discussion on FreeOrion seeks C++ programmers willing to learn. within the Projects and Job Recruitment forums, part of the Community Boards category; Originally Posted by abachler The proper way to fix it is to use teh static libraries, not the DLL's. It ...

  1. #16
    Registered User
    Join Date
    Nov 2009
    Posts
    5
    Quote Originally Posted by abachler View Post
    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...

  2. #17
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Geoff the Medio View Post
    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.
    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.

  3. #18
    Registered User
    Join Date
    Nov 2009
    Posts
    5
    Quote Originally Posted by abachler View Post
    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.

  4. #19
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Geoff the Medio View Post
    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.
    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.

  5. #20
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    Quote Originally Posted by Geoff the Medio View Post
    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.
    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.

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

    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...
    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?
    The programmerís wife tells him: ďRun to the store and pick up a loaf of bread. If they have eggs, get a dozen.Ē
    The programmer comes home with 12 loaves of bread.


    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.

  6. #21
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Mario F. View Post
    Still, I disagree with abachler in that I suggest you keep your crt dynamically linked.
    Quote 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.
    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.

  7. #22
    Registered User
    Join Date
    Nov 2009
    Posts
    5
    Quote Originally Posted by abachler View Post
    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...

    Quote Originally Posted by Mario F. View Post
    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.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Advice on how to being to learn C++
    By VenomUK in forum C++ Programming
    Replies: 9
    Last Post: 05-18-2002, 01:06 PM
  2. Programming Puns
    By kermi3 in forum A Brief History of Cprogramming.com
    Replies: 44
    Last Post: 03-23-2002, 03:38 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21