CEGUI (Crazy Eddie's GUI) Forums

Sorry if this is a resolved issue, but after much time poking around on various forums it still isn't clear to me if the whole CEGUI/MinGW thing has been resolved.

- Is there a wiki page that shows how to build 6.2 for minGW?
- Is there a more appropriate place where I should be posting?

I'm using Ogre SDK 1.4.2 with the MinGW_Toolbox_Setup (gcc 3.4.5?) and Code::Blocks 8.02.

BTW - great package. Thanks for all your work!

Hi, and welcome

MinGW support is tested by myself via a cross-compiler on linux. I believe there are a handful of people who have gotten it to work - so it can be done.

I believe that the CEGUI 0.6.2 code will compile fine with the MinGW build system, the real issue is with the dependency libs that we do not provide - if you can get those, or build those, you should be fine.

CE.

Ok - great. I was unsure because there seems to be a lot of posts on various forums (some obsolete) about past problems related building CEGUI with MinGW, including people who gave up on it, so I was reluctant to dive in.

I'll try it and see how it goes and I'll post my progress here (as time allows). If anyone else has any experience with this then please chime in.

Thanks CE.

ok - I've been working on this as time allows and I finally worked through the process of installing MSys, building autoconf, automake, libtools, pkg-config, yada, yada, and I was finally able to get CEGUI6.2 to bootstrap, configure, make and install (woot!). I'll post the steps that I had to go through in case there's any other noobs out there who might find it helpful. But first I need to get it working in my program.

Couple of noobish questions first -

1) make/install generated both .dll files (/bin) and .a/.la files (/lib).
Ogre3d+CEGUI6.0 was linking directly against the CEGUIBase.dll file
and didn't come with any library files. What decides whether to link
against the .a or the .dll file? Static .vs. dynamic?

2) The build generated (among other things)

libCEGUIBase.dll.a
libCEGUIBase.la
libCEGUIBase-1.dll

- Why the '-1' suffix on the .dll file? libCEGUISampleHelper-1.dll also
has a '-1' suffix and libCEGUIOpenGLRenderer-0.dll has '-0'.

- Why the 'lib' prefix? Ogre3d+CEGUI6.0 was just named CEGUIBase.dll.
Did they strip the prefix, or is this a new addition?

3) How do I generate a DEBUG version?

4) I notice that you include DirectX, OpenGl, and Irrlicht render modules,
but not Ogre3D. Is this just a matter of not enough time and resources
to cover everything, or would you recommend Irrlicht over Ogre3d?

thanks!

gamecat

Hi,

It's good that you have got this working, or almost! And thanks in advance for posting the steps required to do it - while I generally test MinGW via a cross compile now and then, it's not something we're able to easily support (mostly due to time / manpower type issues).

1) Normally dynamic linking will be preferred when you specify libraries to link with (for example -lCEGUIBase), however you can explicitly get static linking by either specifying the "-static" linker option (which might be considered the "correct" way), or removing the -lCEGUIBase and/or similar reference(s) and instead referencing the static archive directly as if it were another object module (which is also perfectly valid, though obviously does not have the advantage of using library search paths).

2) The suffixes on the DLLs is related to libtool versioning (like on linux where you have, for example, libCEGUIBase.so.1.2.0). It's a similar situation for the 'lib' prefix, it's kind of the standard approach to naming that the autotools build spits out. I actually thought I'd removed those under MinGW - apparently I must have forgotten to actually get around to it

3) For debug/release versions, there are a couple of considerations. First you need to specify appropriate compiler flags for the configuration - on linux this can be done by indicating the CXXFLAGS at configure time - so you might use something like "-O2 -g0" for release and "-O0 -g3" for debug. In addition, for debug builds you can add the "--enable-debug" option when running configure.

For example, debug build configure:


Another consideration is that under autotools, we do not generate different named modules for the two build configs (in fact that's only done under MSVC++).

4) The Ogre renderer module was transplanted from our code base into the Ogre code base as a favour to the Ogre project - it's technically still our code, and we will be providing a new version of that shortly to coincide with some large changes we're making in CEGUI.

We do not recommend any engine or API over any other. Every engine has pros and cons, and it's important to evaluate those in the context of whichever project you're developing and then choose an appropriate engine (a politicians answer? )

I'm not sure how the MinGW CEGUI libs provided by the Ogre guys are generated, but it's probably not via the configure script (you'd have to ask them to be sure ).

Hope this answers some of the questions.

CE.

Success. I still haven't figured out how to build the Debug version and I'm having some other unrelated issues, but I figured that I would post the steps that I took to get from zero to hero for any other poor shlubs who might be trying to wade through this. The process wasn't exactly as linear as I present it, and I may have missed a step or two (although I tried to be thorough), but it may be helpful.

I'm mark the thread as SOLVED as soon as I figure out the Debug build...

=====================================
Building CEGUI for MinGW
=====================================
Starting configuration
----------------------
(as per http://zd.0x209.org/docs/ogre3d/c/o/d/C ... _3144.html)

- MinGW 5.1.2
- Ogre 1.4.9 (Eihort)
- CEGUI 0.6.0 (from OgreDependencies_CBMinGW_Eihort_20080115.zip)
- Code::Blocks 8.02

Steps to build/install CEGUI 0.6.2
----------------------------------
- Download, install to D:\msys\1.0
http://downloads.sourceforge.net/mingw/MSYS-1.0.10.exe
http://downloads.sourceforge.net/mingw/ ... -1.0.1.exe
http://downloads.sourceforge.net/mingw/ ... -1.tar.bz2

- download, unzip and install m4.exe into D:\msys\1.0\bin
http://downloads.sourceforge.net/mingw/ ... YS.tar.bz2

- Download, save to D:\OpenSource\Packages (or where you like)
http://ftp.gnu.org/gnu/autoconf/
http://ftp.gnu.org/gnu/automake/
http://ftp.gnu.org/gnu/libtool/

- From MSYS shell:
$ d:/opensource/packages/autoconf-2.63/configure --prefix=/mingw && make && make install
$ d:/opensource/packages/automake-1.10.1/configure --prefix=/mingw && make && make install
$ d:/opensource/packages/libtool-2.2/configure --prefix=/mingw && make && make install

I made autoconf first and it built ok, but automake and libtool failed with,

make: *** No rule to make target `d:/opensource/packages/automake-1.10.1/maint.mk'. Stop.
make: *** No rule to make target `d:/opensource/packages/libtool-2.2/maint.mk'. Stop.

so I copied D:\OpenSource\Packages\autoconf-2.63\maint.mk to ...\packages\automake-1.10.1
and ...\packages\libtool-2.2. I was then able to build all three packages.

- From http://www.gtk.org/download-windows.html, download and unzip into D:/mingw

Pkg-config 'Tools Binaries' (pkg-config-0.23-2.zip)
GLib 2.18.4 Binaries (glib_2.18.4-1_win32.zip)
Freetype 2.3.6 Dev (freetype-dev-2.3.6.zip)

- from http://gnuwin32.sourceforge.net/packages/pcre.htm (Developer Files),
download and unzip into D:/mingw...

pcre-7.0-lib.zip
pcre-7.0-bin.zip

- Based on info in http://www.mingw.org/wiki/msys and trail & error, add the following to D:\msys\1.0\etc\profile...


PKG_CONFIG_PATH="/mingw/lib/pkgconfig"
CVS_RSH=ssh
CFLAGS="-pipe -O2 -mms-bitfields -march=i686"
export HOME LOGNAME MSYSTEM HISTFILE CFLAGS PKG_CONFIG_PATH CVS_RSH
export ACLOCAL_FLAGS="-I /mingw/share/aclocal -I /mingw/share/aclocal-1.10"

- As per "http://www.cegui.org.uk/wiki/index.php/HOWTO:_Obtain_ the_library_source_
from_subversion" download and unzip CEGUI-0.6.2b.zip into a location of you choice

- Follow the "Compiling on Linux" directions

From the MSys command line...
--------------------------------------
$ cd (the dir that you unzipped cegui-0.6.2 into)

$ ./bootstrap
libtoolize: putting auxiliary files in `.'.
libtoolize: linking file `./ltmain.sh'
libtoolize: You should add the contents of the following files to 'aclocal.m4':
libtoolize: `/mingw/share/aclocal/libtool.m4'
libtoolize: `/mingw/share/aclocal/ltoptions.m4'
libtoolize: `/mingw/share/aclocal/ltversion.m4'
libtoolize: `/mingw/share/aclocal/ltsugar.m4'
libtoolize: `/mingw/share/aclocal/lt~obsolete.m4'

- Add the contents of the above files to cegui-0.6.2/aclocal.m4

From the MSys command line...
--------------------------------------
$ ./configure --prefix=/mingw
$ make
$ make install

- If the build and install completes successfully, then drink a beer or three


Stuff installed
---------------
mingw/include/CEGUI - 172 files .h files / 8 folders

mingw/bin -

libCEGUISampleHelper-1.dll
libCEGUIFalagardWRBase.dll
libCEGUIOpenGLRenderer-0.dll
libCEGUITGAImageCodec.dll
libCEGUITinyXMLParser.dll
libCEGUIBase-1.dll

mingw/lib

libCEGUIBase.dll.a
libCEGUIBase.la
libCEGUIFalagardWRBase.dll.a
libCEGUIFalagardWRBase.la
libCEGUIOpenGLRenderer.dll.a
libCEGUIOpenGLRenderer.la
libCEGUISampleHelper.dll.a
libCEGUISampleHelper.la
libCEGUITGAImageCodec.dll.a
libCEGUITGAImageCodec.la
libCEGUITinyXMLParser.dll.a
libCEGUITinyXMLParser.la

mingw/share/CEGUI/

configs/
fonts/
imagesets/
layouts/
looknfeel/
lua_scripts/
schemes/
XMLRefSchema/

=====================================
Updating Ogre3d (w/Code::Blocks) with CEGUI 0.6.2
=====================================

CEGUIRenderer
------------------
- Load the
..\Ogre3d\Samples\Common\CEGUIRenderer\scripts\OgreCEGUIRenderer.cbp codeblocks project and rebuild DEBUG and RELEASE.

Here's what my 'Global Compiler Settings' look like...

Linker Settings: NONE

Search Directories: Compiler
D:\Mingw\include
D:\Mingw\include\CEGUI
D:\Mingw\include\CEGUI\elements
D:\mingw\include\CEGUI\falagard
$(OGRE_HOME)\OgreMain\include
$(OGRE_HOME)\Dependencies\include
$(OGRE_HOME)\Dependencies\include\OIS
$(OGRE_HOME)\Dependencies\include\ode
$(OGRE_HOME)\Dependencies\include\CEGUI
$(OGRE_HOME)\Samples\Common\CEGUIRenderer\include
D:\Microsoft DirectX SDK (June 2008)\Include

Search Directories: Linker
D:\mingw\lib
$(OGRE_HOME)\lib
$(OGRE_HOME)\Dependencies\lib\$(TARGET_NAME)
$(OGRE_HOME)\Samples\Common\bin\$(TARGET_NAME)
D:\Microsoft DirectX SDK (June 2008)\Lib\x86

and the OgreGUIRenderer project build options are...

Linker Settings / Linker options (DEBUG+RELEASE)
-Wl, --enable-auto-image-base
-Wl, --add-stdcall-alias

Release link Libraries:

OgreMain
libCEGUIBase.dll

Debug link Libraries:

OgreGUIRenderer_d
libCEGUIBase.dll (haven't build a debug version yet)


Your project
--------------
- Rebuild your Ogre/CEGUI program in Code::Blocks.

My project specific build options are:

Linker Settings / Linker options (DEBUG+RELEASE)
-Wl, --enable-auto-image-base
-Wl, --add-stdcall-alias

Release link Libraries:

OgreGUIRenderer
OgreMain
ois
ode
libCEGUIBase.dll

Debug link Libraries:

OgreGUIRenderer_d
OgreMain_d
ois_d
ode_d
libCEGUIBase.dll (haven't build a debug version yet)

Your promises of wonder were nothing but lies! I kid I kid.

All seemed to be going well for me until I ran the configure script, which threw this error

checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
./configure: line 15737: syntax error near unexpected token `freetype2,'
./configure: line 15737: `PKG_CHECK_MODULES(freetype2, freetype2 >= 0.15.0)'

I seem to recall getting derailed at the some point. Your pkg-config isn't setup properly. Double check that portion. I spent a day or two trying to build pkg-config before I gave up and found a prebuilt on http://www.gtk.org/download-windows.html, so maybe I ended up setting something up differently during that time. Check that pkg-config-0.23-2.zip was installed properly.

Make sure that you have

mingw/bin/pkg-config.exe
mingw/share/aclocal/pkg.m4

In checking my directory struct, I found that I also have a copy of pkg.m4 in my mingw/share/aclocal-1.10 dir, so copy it over to there as well. Perhaps that's the difference.

I haven't figured out why I have both an aclocal and aclocal-1.10 directory, but at this point my desire to move on overrides my curiousity.

Here's what I ended up with in each...

\mingw\share\aclocal-1.10

amversion.m4
as.m4
auxdir.m4
ccstdc.m4
cond.m4
depend.m4
depout.m4
dmalloc.m4
gcj.m4
header.m4
init.m4
install-sh.m4
lead-dot.m4
lex.m4
lispdir.m4
maintainer.m4
make.m4
minuso.m4
missing.m4
mkdirp.m4
multi.m4
obsolete.m4
obsol-gt.m4
obsol-lt.m4
options.m4
pkg.m4
protos.m4
python.m4
regex.m4
runlog.m4
sanity.m4
strip.m4
substnot.m4
tar.m4
upc.m4

\mingw\share\aclocal

argz,m4
freetype2.m4
libtool.m4
lt~obsolete.m4
ltdl.m4
ltoptions.m4
ltsugar.m4
ltversion.m4
pkg.m4

Good luck!

gamecat wrote:In checking my directory struct, I found that I also have a copy of pkg.m4 in my mingw/share/aclocal-1.10 dir, so copy it over to there as well. Perhaps that's the difference.

That fixed the problem and the configure script works, although I have lua installed(In my fairly amateur world that means I can run lua -i and putting -llua in a g++ command throws no errors) and configure doesn't seem to see this and won't build the lua module.

My next problem was that make couldn't find C:\msys\1.0\mingw\lib\dllcrt2.o. Which makes sense because it didn't exist but C:\MinGW\lib\dllcrt2.o did, so I copied it and everything else with the words crt in C:\MinGW\lib to C:\msys\1.0\mingw\lib. This leads me to a question, what's with the mingw directory in msys? Should I just copy everything I have in C:\MinGW to it?

Finally I'm stuck here, I run make install and it ends with this.

Making install in TinyXMLParser
make[2]: Entering directory `/c/CEGUI/XMLParserModules/TinyXMLParser'
make[3]: Entering directory `/c/CEGUI/XMLParserModules/TinyXMLParser'
test -z "/usr/local/lib" || /bin/mkdir -p "/usr/local/lib"
/bin/sh ../../libtool --mode=install /bin/install -c 'libCEGUITinyXMLParser.la' '/usr/local/lib/libCEGUITinyXMLParser.la'
libtool: install: /bin/install -c .libs/libCEGUITinyXMLParser.dll.a /usr/local/lib/libCEGUITinyXMLParser.dll.a
libtool: install: base_file=`basename libCEGUITinyXMLParser.la`
libtool: install: dlpath=`/bin/sh 2>&1 -c '. .libs/'libCEGUITinyXMLParser.la'i; echo libCEGUITinyXMLParser.dll'`
make[3]: *** [install-libLTLIBRARIES] Error 1
make[3]: Leaving directory `/c/CEGUI/XMLParserModules/TinyXMLParser'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/c/CEGUI/XMLParserModules/TinyXMLParser'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/c/CEGUI/XMLParserModules'
make: *** [install-recursive] Error 1

Finally I have one more question, do I have to do this? I'm doing this because I assumed that the CEGUI I got with the Ogre SDK only works with Ogre, so are you doing this because my assumption is true or is this just something for people who want the latest version of CEGUI?

> ...configure doesn't seem to see this and won't build the lua module

I'm not dealing with lua, so I can't help you there.


> ...what's with the mingw directory in msys?

I have a /msys/mingw directory, but mine is empty. Not sure when yours got filled.


> Making install in TinyXMLParser
> make[2]: Entering directory `/c/CEGUI/XMLParserModules/TinyXMLParser'
> make[3]: Entering directory `/c/CEGUI/XMLParserModules/TinyXMLParser'
> test -z "/usr/local/lib" || /bin/mkdir -p "/usr/local/lib"
/bin/sh ../../libtool --mode=install /bin/install -c 'libCEGUITinyXMLParser.la' '/usr/local/lib/libCEGUITinyXMLParser.la'
> libtool: install: /bin/install -c .libs/libCEGUITinyXMLParser.dll.a /usr/local/lib/libCEGUITinyXMLParser.dll.a
> libtool: install: base_file=`basename libCEGUITinyXMLParser.la`
> libtool: install: dlpath=`/bin/sh 2>&1 -c '. .libs/'libCEGUITinyXMLParser.la'i; echo libCEGUITinyXMLParser.dll'`
> make[3]: *** [install-libLTLIBRARIES] Error 1

my 'make install' log looks like this...

Making install in TinyXMLParser
make[2]: Entering directory `/d/opensource/cegui-0.6.2/XMLParserModules/TinyXMLParser'
make[3]: Entering directory `/d/opensource/cegui-0.6.2/XMLParserModules/TinyXMLParser'
test -z "/mingw/lib" || /bin/mkdir -p "/mingw/lib"
/bin/sh ../../libtool --mode=install /bin/install -c 'libCEGUITinyXMLParser.la' '/mingw/lib/libCEGUITinyXMLParser.la'
libtool: install: /bin/install -c .libs/libCEGUITinyXMLParser.dll.a /mingw/lib/libCEGUITinyXMLParser.dll.a
libtool: install: base_file=`basename libCEGUITinyXMLParser.la`
libtool: install: dlpath=`/bin/sh 2>&1 -c '. .libs/'libCEGUITinyXMLParser.la'i; echo libCEGUITinyXMLParser.dll'`
libtool: install: dldir=/mingw/lib/`dirname ../bin/libCEGUITinyXMLParser.dll`
libtool: install: test -d /mingw/lib/../bin || mkdir -p /mingw/lib/../bin
libtool: install: /bin/install -c .libs/libCEGUITinyXMLParser.dll /mingw/lib/../bin/libCEGUITinyXMLParser.dll
libtool: install: chmod a+x /mingw/lib/../bin/libCEGUITinyXMLParser.dll
libtool: install: if test -n '' && test -n 'strip --strip-unneeded'; then eval 'strip --strip-unneeded /mingw/lib/../bin/libCEGUITinyXMLParser.dll' || exit 0; fi
libtool: install: /bin/install -c .libs/libCEGUITinyXMLParser.lai /mingw/lib/libCEGUITinyXMLParser.la


Note the difference:

test -z "/usr/local/lib" || /bin/mkdir -p "/usr/local/lib"
.vs.
test -z "/mingw/lib" || /bin/mkdir -p "/mingw/lib"

Did you specify "--prefix=/mingw" when you ran ./configure? If not, then "make clean" and strat over again.


> Finally I have one more question, do I have to do this?

I tackled this for three reasons -

1) The CEGUI binaries that came with Ogre were version 0.6.0. As far as I could find, there are no mingw binaries available for CEGUI 0.6.2, so in order to upgrade I had to build.

2) I wanted source code and debug .dlls available so that I could step into CEGUI if I got stuck somewhere.

3) I figured that it would be a way to learn how to build open source projects in general.

You're welcome to use any of the above reasons, or come up with some new ones.

gamecat

OffbeatPatriot wrote:I have lua installed ... configure doesn't seem to see this and won't build the lua module.

You should be able to add Lua_CFLAGS and Lua_LIBS definitions on the configure command line that point to the appropriate place(s) and define the required flags, this avoids the pkgconfig check and effectively forces the lua module to build (but you have to ensure the vars are set correctly, of course).

CE

Getting back to the debug build...

I'm able to build a debug version using the flags, but isn't there any way to get the build scripts to add a suffix? It doesn't seem possible to just rename the binaries and libs after the fact, as I believe that the name is encoded into the file.

I can create Debug/Releasee subdirectories under mingw/lib and link against them, but then I have to copy the correct version of the .dll into my executable directory whenever I change between debug and release. Unless maybe there's a way to dynamically specify a directory for picking up .dlls at runtime?

Anyway, it would be best if each had unique names. Is there a straight forward mod that I can make to my scripts? Thanks!

gc

gamecat wrote:Getting back to the debug build...
it would be best if each had unique names. Is there a straight forward mod that I can make to my scripts? Thanks!

As far as I know, you'd have to modify the makefile and configure set up to support a suffix and then rebuild; you then also need to modify the source to ensure that CEGUI adds the appropriate suffix when it's loading modules (such as WindowRenderer modules, XML parsers, ImageCodecs etc). Overall it's not a hard change to make, but neither is it a trivial change.

For my part, I am willing to add a means to support this for future releases - since being able to add a suffix to all modules has other uses beyond just a _d for debug.

CE.

That would be great.

Just out of curiousity, how do others currently handle this? Am I the only interested in building a debug version. or do other users set up scripts to shuffle the correct files in place? Is there a standardized way of creating debug builds in the OSS community?

Thanks CE.

I'm quite sure there is a option you can pass to the configure script that adds a suffix or a prefix! check ./configure --help
I think that's how I did it.

You can also just build the whole thing in two different folders (including the binary), that's what m$ does