A Special Kind of Hell

I've spent the majority of today attempting to get Synergy to compile.

Basically, as far as I can tell, after I formatted my computer some time ago and reinstalled MSVC++ 2008, reinstated all the libraries that Synergy uses (Allegro, AllegroGL & SOIL), at some stage something went wrong.

I loaded up the .sln file, and hit Build, and I was confronted with one of the strangest errors I've seen in a while: something about an inline assembly code error, expected an opcode and found a data type, or something bizarre like that.

I started to systematically compile each individual .cpp file, and found that all of them except 1 compiled just fine. The troublemaker that caused the problem was gam_Entity.cpp, which is weird because that's a very simple source file, with very few dependencies and very straight-forward class-definition-style code.

So I kind of fiddled around in that file, commenting out sections of code and recompiling, trying to find a particular line that spouted the error, and I found that no line caused it, since I ended up commenting out the entire .cpp and .h files! By this point I was just downright flabbergasted, and I turned to google for help.

I found a couple of pages that mainly went through fiddling with project properties, cleaning out .obj itermediary files, that sort of thing. But none of those seemed to fix it. So then I started thinking maybe it was something about where Allegro was being included, so I started including allegro.h and alleggl.h at different points in the header file, commenting out includes, trying #include instead of #include "allegro.h", random trial and error things like that.

I don't remember exactly at what point it worked, but somewhere it worked. As far as I can tell, no one thing that I did fixed it, it just seemed to `come good', which is troubling.

Anyway, after that assembly error stopped coming up, I had a new set of errors coming up; a tonne of link errors. Welcome to the next nightmare. This was basically about 180 LNK2001 errors saying various identifiers had already been included in .obj files. I did more scanning of the net and went a little crazy, and then I realised I had actually gone through all the functions in m_common.h and removed the inline from the beginning of each non-template function definition in an attempt to fix the previous problem. Dur. So I replaced the inlines and bam! No more link errors.

But then I got a single error; something about P1 and P2 being different versions. Scanning the net more, I found out this relates to the compiler having incosistent versions of itself, or that libraries that I'm using have been compiled with different version compilers, something quite likely. So then I kind of started losing my mind, and tried bringing in different versions of each library to MSVC++ 8.0, downloading and installing MSVC++ 9.0 and installing the libraries for that, and even going back to MSVC++ 6.0 and trying there.

What I ended up with was uninstalling 8.0 sort of out of some irrational belief that it would help to quell the curse upon my computer, but also (more rationally) that I should try reinstalling it at some point and carefully version checking each library I bring into it.

MSVC++ 9.0 overcame the P1 != P2 error, but now SOIL.lib was spouting a couple of link errors to unresolved external symbols __alloca() and something else. So now I'm quite lost. My guess is some version inconsistency between the 9.0 compiler and the compiler that SOIL was written for, ie SOIL only compiles on 8.0 or earlier, or something like that. That's something I mean to test when I reinstall 8.0.

I then tried to comment out the SOIL code and I was left with a single link error about MSVCRT not being able to locate _main. So I followed some instructions on a website to fiddle with the MFC settings in the project settings, which just spawned more errors so I reverted back to EXACTLY how the settings were, and now I have 7 errors. It's absolute madness!

MSVC++ 6.0 finally managed to compile and execute an older version of the code once I commented out all reference to SOIL. This is basically the best result that I've achieved. At this point I'm looking at bringing in all the code that I've written since this old version, getting it to function, and then (hopefully!) compile and run. At that point I'll be back to where I was, except in 6.0 instead of 8.0, to which I say good riddance. This might also be a good time to rid myself of AllegroGL for good. One lesson I take from this is `the less dependencies, the better'.

So there it is, my special kind of hell. To be honest, this should never have happened. Part of the function of this blog is to act as an engineering journal, where I can record version changes and things I do to my projects which might end up leading to something like this current scenario in the future. I should have had logged which version all of my libraries, IDE and compiler were and the directory of my last known successful build of Synergy.

I won't make the same mistake again.

--------------------------------------------------

Synergy Version: 0.0.0
IDE Version: MSVC++ 6.0
Allegro Version: 4.2.2
AllegroGL Version: 0.4.2
SOIL Version: 2008/07/07

Current Status:

• Compiling & Executing
• SOIL producing two LNK2001 errors; all SOIL references have been commented out
• Thus, textures currently not loading
• Old demo version; multiple smoothed 3D objects floating in space

To Do:

• Eliminate all AllegroGL dependency
• Fix texture loading
• Implement multicore functionality
  
• Reintegrate following features:

1. multiple material meshes
2. the `Big Room' demo
3. lightmaps
4. unified lighting attenuation system

• Implement uniform lightmap patching system
• Implement physics library integration