CEGUI (Crazy Eddie's GUI) Forums

Hello all.

I'd like to build the latest CEGUI HG snapshot using MinGW and CMake. Compilation goes fine, but I have some (well, actually, only one now) linker issues.

First, I got a few undefined reference errors in PCRERegexMatcher.cpp.obj, but after doing a quick search, I was able to eliminate it by adding "#define PCRE_EXP_DECL extern" before "#include <pcre.h>" in PRERegexpMatcher.h. I'm not sure what is this, since I honestly know nothing about PCRE, but it worked.

After this, I got undefined reference erros again, but this time in MinizipResourceProvider.cpp.obj, and no matter what I did, I'm stuck.

Here are the exact errors:


First, I've tried to link against the ZLib version included with the dependencies pack (the pack itself is also the latest Mercurial snapshot), nothing changed. After searching around, I found basically nothing regarding these calls. Well, I found only one forum post where the poster had similiar linker errors when trying to compile the ZLib windows api. They managed to solve this by adding "#define ZLIB_WINAPI" before including zlib. So I tried to add this line before "#include "minizip/unzip.h"" in MinizipResourceProvider.cpp, but nothing happened.

What should I do next? Do I really need the Minizip resource provider? I'm going to use CEGUI with Ogre, and Ogre has its own zip reader, so can I just use that to load CEGUI-related resources from zip files?

Also, what is that PCRE stuff? Do I really need that? CMAKE says it's needed for "editbox string validation", but again, I'm not sure what is this for.

Thank you in advance.

Hi,

MinGW with the latest devel code and latest (source based) dependencies is not well tested at all - so thanks for trying that out! Can you please confirm that you are in fact using the source based dependency pack (http://sourceforge.net/projects/crayzed ... p/download), and not an old prebuilt one? This is highly important, since we changed a lot of stuff which could be related to your issue: minizip used to be bundled within the CEGUI source, now it's supplied as an external lib, and similarly, pcre used to be a static lib under all build configurations, by default it's now a dll for dll builds of CEGUI.

If you are already using the source based dependency pack, I suspect the issues could be something as simple as missing definitions that tell the build whether it will be linked against static or dll libs. I thought I'd got all these right, but that's not certain.

If you're using the Ogre renderer along with the integrated OgreResourceProvider (this interfaces to the Ogre resource systems - it's 99% certain you will be using this), then you will not need the minizip support - it will work transparently via Ogre.

The PCRE editbox validation is currently used to limit what can be entered into a single line editbox (we will be modifying / extending this before the next major release to provide other uses too). For example, you can use this feature limit the user to entering just upper case letters, or just numbers, or anything else you might want. This support is additionally used internally by the Spinner widget also (which is based on the single line editbox).

CE.

Hello,

Thank you for your reply.

The dependencies pack I'm using is exactly the one you've linked, built succesfully with the same toolchain I'm using to build CEGUI. (Sorry, at my first post, I was wrong, it's not the latest Mercurial snapshot.)

I'm trying to build CEGUI statically, therefore I'm linking against static dependencies, so the problem might be indeed a missing definition, but I have no idea what that could be, since I can't find anything regarding these linker errors with ZLib/Minizip.

But since this component is not needed when working with Ogre, I'll just leave it out for now.

As for PCRE, it means that it's not necessary, but the single line edit box and the spinner will not work correctly/at all without this component?

U P D A T E:

It all was my mistake, I set up the environment variable of the shared dependencies directory incorrectly. And since the shared version of CEGUI is alway built, it will look for the shared dependencies as well. Now everything works, even the Minizip resource provider, the only thing is that we still need to link CEGUIBase against the shlwapi library.

I'm still experienceing weird things with FreeImage, but it's famous for using weird proprietary internal libraries, and not working 100% correctly with any compiler...

Hi,

For the development code, I can state that static builds are likely somewhat flaky at the moment as regards to those definitions mentioned earlier and also regarding linking to dependencies of dependencies - I have done some work on that, but there is still some more to do before we finally get around to releasing this The main reason that this is lacking right now is that it's not a config that I build every day, though of course it should be working right by the time we make the release.

As for PCRE, it means that it's not necessary, but the single line edit box and the spinner will not work correctly/at all without this component?

Even though you have PCRE working now, I will answer this question, since it's could be an interesting point. The editbox will work just fine without PCRE, but the validation functionality will not be available. The spinner would be more limited - I think you would need to set the editbox part to read-only and allow manipulation with the increase/decrease buttons only (to stop the user typing invalid strings).

CE

Thanks for your reply.

After many hours of trial and error (and even experiencing with Visual Studio 2010), I gave up, but I think what I managed to build is enough.

I've built CEGUBase, CEGUICommonDialogs, CEGUICoreWindowRendererSet, CEGUIOgreRenderer, and CEGUIRapidXMLParser (I've chosen this one as the default).

I wanted to build the FreeImage codec, but it just failed, no matter what I did. I also wanted to build the demos (configured to use the Ogre renderer), and apart from the font demo, all of them were built, along with CEGUISampleHelper. And, to my surprise, they work (and they run quite fast, around 300-400 FPS). But how is this possible if there is no image loader? Or when using Ogre as a renderer, CEGUI can not only use its zip archive reader, but its image loader as well? And so, these are all the components I need when working with Ogre?

I feel a bit dumb for not putting 2 + 2 together here, regarding the fact you're using Ogre and the previous mentions of FreeImage Yes, you are correct, when using the OgreRenderer via the bootstrapSystem start up functions, the default is to use the image loading provisions available in Ogre - in this scenario you can safely not worry about which ImageCodec is built and set as default in CEGUI (though a default does need to be set - but it can be one that does not exist!)

Those libs you mention are pretty much all you need when using Ogre, yes. Unless you want the colour picker dialog, you can leave out the CEGUICommonDialogs module, too.

CE.

And I feel dumb for not realizing it uses Ogre for image loading, even the startup console says it does...

Anyway, thank you for explaining all the things, and of course, thank you for making CEGUI. I'm already surprised how much it has been improved since I first seen it (it was bundled with Ogre, about 7 years ago, I think), and I hope things will go well and we will see a stable release soon.