Dependency updates, static linking

· by Steve · Read in about 3 min · (637 Words)

I spent yesterday sorting out all the dependencies for Eihort - that meant updating to the latest versions of almost everything. For the core that meant rebuilding FreeType (v2.3.0), FreeImage (CVS - I submitted a patch because they had a small scoping bug in VC8), and Zziplib (0.13.47). I’m building all these with VC8 SP1 now, since I intend to supply binaries for Eihort with the SP installed. For the recent Dagon stable release I used my laptop which doesn’t have SP1 on it, to make it easier to update for those who are sans-SP1, but with Eihort it’ll be full-bore only.

For the samples I also updated OIS (CVS v1-0 branch), CEGUI (SVN v0-5 branch), and ODE (0.8 rc1). Cg will remain on 1.4.1 for the moment since Cg 1.5 has a little bug with vs_1_1 which means it goes into an infinite loop if you use matrix multiplication in a loop which needs unrolling, which we do in our skeletal animation shaders. Since vs_1_1 is still important to some people we need to stick to the previous versions, even though Cg 1.5 does solve a number of the higher-spec shader problems that have forced us onto HLSL/GLSL combos in the past (the ‘dependent tex-op sequence too long’ problem). Luckily I’ve been talking to NVidia and they say the inifinite loop problem is solved in the next version of Cg (after 1.5), and although it’s not in beta yet I should be able to get my grubby hands on a NDA test copy soon to confirm that.

If you have VC8SP1 and are using Eihort from CVS, I’ve uploaded a new dependencies package to Sourceforge, grab them from there. This won’t appear on the official downloads list until we release 1.4.0 RC1 to the general public.

The other thing I’m working on is official static linking targets. Whilst the DLL targets are still the most appropriate for LGPL users who don’t want to release their own source code (or object code), those opting for the alternative OGRE Unrestricted License will be able to statically link without the need to distribute either, so I figured I should make it easier to do. It’s not that hard for anyone who knows their way around a compiler, but it’s also a convenience & organisation thing - so I’m adding extra build targets to cover this. While I’m at it, I’m enhancing the plugins interface a bit so that the process of installing plugins from either a DLL, or from a static library is much more obvious. It also adds the ability to enumerate installed plugins from the outside, which might be useful for tools etc.

What was really interesting though was just how massive the static libs are. For example, the BSP plugin (in release mode) is a 160k DLL and a 3k lib. When linking statically it becomes a 16Mb .lib! OgreMain is even larger. No need to panic, when you finally link all the stuff together it reduces down to smaller than the equivalent DLLs that you would have to distribute before. So why does this happen? I was scratching my head too, until someone reminded me that when building a library VC doesn’t eliminate duplicated inlined code which is indirectly used from other libs, since there is no /OPT option when building a static lib. When you come to build a final binary, that duplication is all removed. Because we use a lot of inlining of critical code (for performance reasons), it makes a fair difference. The STL also has a lot of templated code which does the same thing. It all comes out in the wash, but it means I probably won’t make a static linked SDK because of the size, even though the .lib files compress quite well (no doubt helped by the duplication).