History: Setting Up An Application - CodeBlocks

Code::Blocks & MinGW 3.4.5 & STLPort 5.0

Have a look at the build options for Demo_CameraTrack, most of the demos use the same build options.

Note: with MinGW gcc 3.4.5 you can link directly against dll's built by gcc 3.4.5 and do not require an import lib. This is the same setup on Linux where you link directly to the shared object (.so). This is why the SDK does not come with import libs for Ogre. You don't need them.

Build options that you should use:

Normally you will have two targets: Debug and Release.

To create a new target:

1. Right click on the project in the Management window and select Properties in the popup and this will open up the properties window for your project.
2. Select the Target tab.
3. Select Add to define a new target.
4. Type in the target name ie Debug.
5. Select OK.

Select Build Options to modify build options for a target.

Project build options

will be used for both Debug and Release target build options:

ensure Selected compiler is: GNU GCC Compiler

• Compiler
  • Other options
    • -mthreads
    • -fmessage-length=0
    • -fexceptions
    • -fident
  • '#defines'
    • _STLP_NO_CUSTOM_IO

If your app does not define any custom IO templates then this define will speed up compiles.

• _STLP_USE_DYNAMIC_LIB

this ensures that the DLL version of STLPort is used.

• Linker
  • Other linker options:
    • -Wl,--enable-auto-image-base
    • -Wl,--add-stdcall-alias
• Directories
  • Compiler
    • $(OGRE_HOME)\stlport\stlport

VERY IMPORTANT: The stlport include directory has to be first in the include directories. If it is not then headers used for libstdc++ could get included which will cause conflicts with stlport during the link stage. You will most likely get undefined reference error messages with member methods saying they require std::string (method parameters). You should never see std:: in an error message and if you do then it means that the STLPort headers were not found and libstdc++ headers were used instead. If you do end up in this scenerio, after you correct the directory problem you must do a rebuild so that everything gets recompiled with the proper headers. Selecting build won't do it since CB will just attempt to do the link stage again since it doesn't detect any changes in the source and will fail again.

• $(OGRE_HOME)\include
• Your project include directories
• Linker
  • $(OGRE_HOME)\bin\$(TARGET_NAME)

Code::Blocks

Debug build target options:

ensure Selected compiler is: GNU GCC Compiler
set Policy to 'Append target options to project options'

• Compiler
  • '#defines'
    • WIN32
    • _DEBUG
    • _WINDOWS
    • _STLP_DEBUG

this tells STLPort to use the special debug build version of the dll

• Linker
  • Link libraries:
    • Your project dll's or static libs (.a)
    • OgreMain_d

this is the name of the debug build of OgreMain dll.

• stlportstlg.5.0

this must be the last entry

Release build target options:

ensure Selected compiler is: GNU GCC Compiler
set Policy to 'Append target options to project options'

• Compiler
  • '#defines'
    • WIN32
    • NDEBUG
    • _WINDOWS
• Linker
  • Link libraries:
    • Your project dll's or static libs (.a)
    • OgreMain

this is the name of the release build of OgreMain dll.

• stlport.5.0

this must be the last entry

Note: OGRE_HOME is a pre-defined environment variable setup by the SDK installer. OGRE_HOME points to the directory where the SDK is installed. You can use $(OGRE_HOME) within your build options when setting up paths to specific directories with the SDK that you will need to access.

WARNING Do not mix dll and static object builds using different STL implementations. Here is an example: You build a dll using stdlibc++ but your exe is built using STLPort. Everything that is c++ must be built using STLPort. This does not apply to C static libs and dll's.