Ad blocker interference detected!
Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers
Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.
Ok, the validate Windows build page was hopelessly out of date and broken after several tries clean reinstalls with different versions of tools on two machines. Oddly, the glorious config software produced a bewildering set of new errors if minor variations in tool versions or locations was attempted. I suspect people hack the config to make it work the first time and afterwards just do makes and ignore the horror of installation in favor of getting to messing with the real code.
It's no way to run a railroad. Cross platform development is tough especially with a codebase that is destabilized by constantly updated tools. Too early to form an opinion about why this makefile setup is so impossibly difficult for novices to attempt. It seems to me that if it is so easy that there should be at least one page with up to date information on how if the person follows the exact steps on a current version of Windows that the make is guaranteed to run.
Ok, Install-Windows got the furthest and was updated much more recently (2011) than the Compile-Windows-Authentication page (2008). There were some anonymous edits fixing broken links but going back to the last edit by a recognized authority, I will work from last version edited by Cproc here. Steps taken:
- clean reinstall- everything nuked.
- Install MinGW, use the 5.1.4 version pointed to, check only box MinGW base tools as recommended.
- "Download latest GTK+". In prior builds I have gotten the latest, but today I shall download the package they pointed to: as being a great "all-in-one bundle of the GTK+ stack"
- The instructions say "Unzip and extract all files to the MinGW root directory. ", so though this seems like it will mix/ overlay stuff we'll just do it the way they do, move the contents of the zip to C:/MinGW so the bins etc are merged. ?102 MB? Wow. That's not a small bit of code
- Cygwin step: Ok, so this is perilous because the versions they will download may well not be the ones they used, unless they specified ver number
- Automake 1.9.6-10 (as specified, not most recent 1.11)
- gettext-devel 0.18.1.1-2 (non specified- chose most recent) I note that Cygwin also picked up the non dev runtime- must be a dependency of automake because that was the only prior item I had checked.
- make. 3.82.90-1 Odd. Doesn't minGw have a make too? nevermind. (non specified- chose most recent)
- Not doing this: Subversion 1.7.6-2 (non specified- chose most recent)
- subversion is sucking in a huge number of dependencies, eg perl and we don't need since we are using tortoise outside this environment. If we want to minimize points of failure, it seems unwise to put in subversion. The MSYS instructions use tortoise not svn, so let's skip this this time. Huh. Gettext required git, so cvs got installed anyway. And automake required perl so we got it anyway.
- did not install libinfo as was required before, nor did I install vi, though that provides some cygwin behaviors I like.
- PATH edit to profile. Used recommended line, but did not postpend $PATH. My current path has lots of additional tools that might get picked up and used when what I really want to know is whether the build needs something not specified.
OK, ready to go.
Config run 1
Build 2.4.0-beta1 with provided autogen.sh line for gtk version. Complaint on no libtoolize. Previously, I have installed libtool from Cygwin. The error text recommends download from " ftp://ftp.gnu.org/pub/gnu/libtool/". Since the automake config thing seems be running from cygwin bins, I will install there. Downloaded the latest version 2.4. OH for the love of mike. They want you to build the damn thing. Well screw that. I am using cygwin which presumably is satisfactorily recent, and presumably they understand how to install properly into their environment.
Libtool cygwin is pulling in binutils, which includes GNU ASM. It also pulls in some old automakes.
Config run 2
Gets past AcTool because earlier I hacked out the requirement of automake 1.8 from autogen.sh.
Ok it gets through everything but claims it can't find GCC. I noted that the current MinGW had it listed, but we were instructed just to select the minimum tools chekcbox.
Trying current installer from MinGW site, which has C and C++ checkboxes. http://www.mingw.org/wiki/Getting_Started recommends sourceforge's mingw-get-inst whose current version is mingw-get-inst-20120426.exe here
Checking C, C++, MinGW developer toolkit checkboxes. Dependency- this pulls in MSys automatically, even though I didn't check it.
Config run 3
Now fails automake. Can't find. Likely there is now a conflict between MinGW bins and Cygwin- either that or the MinGW install mucked with the Cygwin dirs. Assume path/ precidence conflict. Flip the order- cygwin is not first, so move MinGw to end.
Have no idea why X11 is there- probably for gtk if that form is built, anyway ignore that stuff.
Config run 4
Ok, passes aclocal, libtoolize, still dies on compiler.
checking for mingw32-gcc... mingw32-gcc checking whether the C compiler works... no configure: error: in `/home/freeciv': configure: error: C compiler cannot create executables See `config.log' for more details
Loading the most recent MinGW is now suspect- It made the path thing necessary, and may have polluted the configuration.
Ok,the config log indicates the gcc is there,but not responding to flags.
configure:3191: mingw32-gcc -V >&5 mingw32-gcc.exe: error: unrecognized option '-V' configure:3191: mingw32-gcc -qversion >&5 mingw32-gcc.exe: error: unrecognized option '-qversion'
configure:3222: checking whether the C compiler works configure:3244: mingw32-gcc -mno-cygwin conftest.c >&5 cc1.exe: error: unrecognized command line option '-mno-cygwin'
Weird. If I gcc -mno-cygwin, it has no problem. Why is this mingw32-gcc so different?
Investigation. GCC is not being run, mingw32-gcc is. And it is a new version that has dropped the deprecated mno-cygwin flag. [http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o this site says mno-cygwin is deprecated. Maybe just try removing the flag from the autogen. Wonder what the flag does.
Config run 5
Ok, stripped the CPPFlag, it gets through compiler check. Barfs on something called Curl.
checking for CURL... no configure: error: libcurl development files required
Ok, this is checking libs and .h's from the config.log, so it probably wants this stuff in MinGw. Not sure, because it is a GNU environment thing so maybe it should be in CyGwin lib. Used CyGwin setup to install "libcurl" from the libs group. This also pulls in dependency zLib.
No luck with downloading libcurl-devel. Same error.
W32 office machien:Decided to download and build it. This is totally nuts. Anyway, loaded what appears the very most recent stable version at the main CUrl site. link to zip
- Make failed with undefined references. Brilliant.
- Ok, after this, W32 civ 2_3 is ready to Make. Did not have to use command line option '-mno-cygwin' because this config apparently has the older gcc compiler. Didn't need to abort the GTK test (--disable-gtktest) maybe because I was careless on the GTK install on the Win64 machine.
For win64 machine (laptop), decided to move build tests over to MSYS since some of these glitches are due to libs and includes getting put incompletely or in the wrong tree.
W64:Found latest version of libcurl and build it. Jeez that was a mofo.
W64: Moved dir from mingw\msys\1.0\local to root directory.
Config run 6
w64- autogen command from install windows page w64- Now complains on inability to run GTK+ test program. THis is such a POS config
Config run 7
Ok, trying config with flag --disable-gtktest Ok, no barfs on config, ready to Make.
W64 Make run 1
Dies in dependencies /Lua 5.1 /src....gcc does not recognize option -pthread. Old GCC?
W32 Make 2.3 run 1
Building Civ 2.3 using MSYS.
Died in utility directory on ./generate_specenum.py Python missing?!?!?
Ok, found something called DTK toolkit for MSYS from the instructions that I neglected to install. Maybe that has python perl and all that stuff. Found it at MSYS page http://www.mingw.org/wiki/MSYS, and installed the one pointed to there. http://downloads.sourceforge.net/mingw/msysDTK-1.0.1.exe . Watching the install, I saw no python. It asked where to install and offered to place in Mingw/1.0, but I chose mingw root like everything else. This may have killed by working build setup, so I will check the config step again. Nuts. One teensy bad decision, and I may have to reinstall the whole GD mess... Now what was that arcane autogen I am supposed to use? Crap this is so innane. Why you can't just type make like in the libcurl directory? Oh yeah- computers are not for making things easy- they are for making things hopelessly arcane. Oh here is the line I forgot: How could this slip my mind? It is so clear, right? Right?
./autogen.sh --enable-client=gtk-2.0 --with-libiconv-prefix=/usr --host=mingw32 CPPFLAGS=-mno-cygwin
Barfed on libtool- wrong version.
Great. The DTK install broke my config.
Back to square one on the Win32 machine- rebuild MinGw environment. Sure- I could just patch it using the MinGw installer and it might work, but then I have non reproducible steps.
Swell. AutoHell round 38.
WTF. I went through all that Autohell stuff for 7 days, which supposedly verifies my config and it doesn't bother to verify existence of Python on my machine? This is such a total POS. I think the KDE guys are completely correct that AutoHell is hopelessly inadequate and arcane for a serious multiplatform project.
All AutoHell does is raise the barrier to entry by naive entry level developers, dissuading them from contributing to open source projects.