Thursday, March 06, 2008

Solving pesky LNK4204 warnings...

So today I finally thought I had the entire build process worked out for the upgrade to VS 2008. Turns out I had one final little hurdle to overcome. After experiencing the mess of trying to integrate third-party libraries into my main base library, I decided to try creating a build hierarchy to significantly reduce build times and my base library project size.

Let me clarify what a build hierarchy is: Basically, I have a base library that I integrate with every software application I write. I've actually got pre-made projects set up that allow me to quickly roll out a new piece of software without wasting 30 minutes each time I go to write a quick little program. Occasionally I have need for a third-party library. Instead of dragging those VC++ projects into each and every solution so that the base library didn't break, I merged the solutions into one project. Yeah, after the fact, it turned out to be not one of my brighter ideas (it generally worked fine though but rebuilds were a huge pain). A build hierarchy is a separate solution where I build a static library or DLL of whatever it is that needs building. Then I just use the output libs in my main library's build process. The idea here is to keep the library layer completely separate from the application layer. I don't ever want to have to edit project settings for the application layer or the library layer.

Basically, I added the path and filename to the .lib file to Properties->Librarian->General->Additional Dependencies and then went and built the project. The test application built but then, for every last .obj file in the third-party .lib, the linker issued a LNK4204 warning despite the .pdb files clearly being in the same directory as the third-party .lib file was. The solution to this was pretty obscure. Apparently all .pdb files generated outside the current solution have to have completely unique names to be used within another solution. This is obscure because you would think that the output .pdb filename from each solution being unique would be sufficient as it contains all the .objs and .pdb data within the .lib and library .pdb. Apparently the linker gets confused if two .pdb names conflict at any level in the hierarchy. VC++ gives a default name to each .pdb, making it somewhat painful to go through each project and override it. Anyway, making all .pdbs have unique names (not just the top-level ones) made all the LNK4204 errors go away and build cleanly (did a Rebuild Solution just to make sure).

I still have quite a ways to go before my development environment is stabilized again but the major hurdles are out of the way. I've basically stalled all development effort until this gets done. I've put in countless hours getting this to work and probably lost some sleep too.

Sleep? What's that?

Wednesday, March 05, 2008

Sigh - library problems

One the third party libraries I occasionally use is called zlib. It offers rudimentary compression capabilities. My upgrade to VS 2008 has been nothing but one headache after another. This latest headache was caused by the optional x86 MASM assembler module for zlib that drastically increases the performance of zlib. Hand-optimized assembler generally outperforms anything else but is tricky to get right in the first place.

Apparently, the optional zlib assembler integration module requires the now ancient and dead MASM32 assembler (remnants of Visual Studio 6 that I appear to have "migrated" to a later release of VS). This time around, VS 2008 includes its own version of MASM, which I didn't want to overwrite. So, the zlib build issued these errors:

inffas32.asm(594) : error A2070: invalid instruction operands
inffas32.asm(596) : error A2070: invalid instruction operands
inffas32.asm(610) : error A2070: invalid instruction operands
inffas32.asm(667) : error A2070: invalid instruction operands

It took hunting through a blog post in a Far Eastern language (probably Japanese) to figure out how to fix the problem. Edit inffas32.asm and change:

movd mm4, [esp + 0]


movd mm4, dword ptr [esp + 0]

At which point, I said "duh" to myself, tried it out, and it worked. I know assembler and thought the line looked weird but couldn't pinpoint why. I figured I'd do my own blog post on this for two reasons:

1) The websites hosting various Chinese/Japanese language blogs are always ultra slow.
2) Not every programmer can "read between the lines". I didn't have to translate the blog to English to know precisely what was being said.

People complain about outsourcing but guess who is coming up with solutions to problems first? I frequently find the most interesting bits of code tucked away within foreign websites - particularly of the Japanese variety. I have never been to an Indian blog as a Google search result.

Saturday, March 01, 2008

Sigh - crashes.

Lots of crashes. I just "upgraded" to Visual Studio 2008 Professional a couple weeks ago. I've been working my way slowly through this incredibly painful upgrade cycle. I knew it was going to be painful in advance, so I have segmented the upgrade to span about three weeks of effort. Let me journey my experience thus far:

1) The first step in this adventure was to uninstall VS 2003. That took a while but actually wasn't very painful.
2) I then attempted to install VS 2008 Pro out of the shiny new box. I didn't want to fiddle with the whole upgrade process so I went ahead and got the full version.
3) Then the installer froze while trying to install. In particular, it froze on attempting to install the 3.0 .NET Framework.
4) This is where things got...complicated. I went out to Microsoft Update and had to do a ton of upgrades (including the annoying spyware install of Windows Disadvantage). After many hours I finally got the 3.0 .NET Framework installed.
5) I then started the install and ran it. It crashed halfway into the install of the main Visual Studio components.
6) I crossed my fingers that it would pick up where it left off, hoped nothing would go horribly wrong in the future, and then started the install again. It seemed to continue where it left off and finished off the install without any more problems.
7) I applied my special fixes to devenv.exe - a symbolic link/symlink patch (see my CodeProject article) - some debugging libraries - various include files and batch file modifications. Basically, a lot of grunt work to connect everything back up. I was hoping this would keep things relatively transparent. Er, that's not quite what happened.
8) I installed the MSDN Library documentation. This took a very long time to complete.
9) At this point I realized that the 64-bit components were not installed and had to go back and install them.
10) I then ran a full Platform SDK upgrade. This also took a while.

That was the end of week one. Roughly 10 hours of effort.

11) I imported an existing project.
12) I attempted to build the existing project. Noticed that Intellisense was busted. Had to delete the relevant .ncb files and restart the IDE to get Intellisense to work properly. Seems to be slightly more intelligent in this version.
13) Existing project libraries failed to build.
14) Upgraded/edited/modified libraries.
15) Multiple crashes occurred while editing property sheet pages. Discovered that VS now seems to back up project files. What would be better would be to fix the crash bugs but at least I lost only minimal data each time it crashed.
16) Managed to get the libraries to build with tons of warnings (even on warning level 3, level 4 warnings were being issued).
17) Discovered that upgraded applications attempt to still locate old VC libraries to link against and fail. Somehow the solution or project still points at the old VC runtimes.

And this is the point where another 10 hours have passed. End of week two.

I'm doing this upgrade in my spare time. My focus is mainly the web forum software MyProBB. I took a break today from working on that to get my development environment stabilized. Again. And I was hoping to work on something exciting too but I'm probably not going to get to that.