Preprocessor output

I’ve been trying to migrate some code from one framework (Gramebryo’s older core) to another (the new Game Framework) and ran into some errors. Here’s some fixes/findings.

I have been diving in to the preprocessed output of source files for a lot of these fixes. In VS2005, use /P or on a source file’s Configuration Properties > C/C++ > Preprocessor > Generate Preprocessed Files.

 

It began with getting some "unresolved external symbols: boost::throw_exception" errors. That was resolved by switching on C++ Exceptions on the (VS2005) project. Without that, BOOST_NO_EXCEPTIONS defined in boost/config/compiler/visualc.hpp (for NewService.i)
This was not defined for older OldCore.i. Depending on that macro, a declaration or definition gets preprocessed from boost/throw_exception.hpp.

(Configuration Properties > C/C++ > Code Generation > Enable C++ Exceptions.)

 

The older project’s debug builds had _STLP_DEBUG enabled, enabling that on the new project got some ambiguous calls to Sleep; on source files which had a particular ‘using namespace’ statement.

Btw, I used a utility called cppdep (by Chris Steinbach) to find the "include chain" of certain headers. I hacked in a little code to it so that it prints out the chain for me; I’ve uploaded the modified cppdep here [x]. Edit: re-hosted on GitHub.

The usage for this version is:

 python explore.py PreprocessedSource.i HeaderToSearch.h.

The output would be something like:

* HeaderToSearch.h

< ParentHeader0.h

 …

< ParentHeaderN.h

< InputSource

 

Anyway, the ambiguous calls were cleaned up by getting rid of the using namespace statements and explicitly using the namespace-name:: where required.

 

Other tools that can be handy when dealing with such issues:

undname.exe decoratedname
This is a command line tool (VS bin directory) that takes the decorated name as it’s first argument and outputs a human readable (un decorated) format of the symbol.
dumpbin /LINKERMEMBER libname.lib | grep SearchSymbolName
Is another useful command line (VS) tool that can be used (apart from other switches) to list the decorated symbols in a lib.

lib /LIST filename.lib

Can be used to list the obj files that comprise of the lib.

 

Then I got some more unresolved external symbols, symbols that I was quite sure existed. Anyway, I opened the lib file that I thought would have the symbol in the (in a hex editor) and searched for the name of the function. After pasting the name of the unresolved symbol from the error/output window and the symbol name from the lib in a text editor; switching off word wrap revealed: the whole name was off by 1 character – stlp vs stlpd. One of the dependent projects also seemed to need _STLP_DEBUG to be defined on it.

Gamebryo uses STLPort and one of projects in the solution uses boost (1.34.1) and that expects _STLP_DEBUG to be defined in debug mode (in boost/config/auto_link.hpp). Though enabling the macro on the dependency breaks as it ends up needing all the Gamebryo libs to have it also enabled. This is something I’m currently trying to work around.

The issue has been fixed. I got rid of the _STLP_DEBUG macro from the projects. Switched off boost’s auto linking feature (BOOST_ALL_NO_LIB). Built the required boost libraries (BOOST_LIB_DIAGNOSTIC) with the runtime-debugging option set to off, the stdlib option set to stlport and linked to them manually.

To build, I used:

Edited tools/build/v2/user-config.jam:
using msvc ;
using stlport : 5.1.5 : D:\…\stlport D:\…\lib ;

and ran:
bjam msvc variant=debug,release threading=multi stdlib=stlport link=shared,static runtime-debugging=off runtime-link=shared stage