CEGUI (Crazy Eddie's GUI) Forums

Ran into unexpected problems with building 0.8.2 in VS 2012. Dynamic configuration is built okay, and the sample framework runs fine. Dynamic configuration with static dependencies - okay, sample framework runs fine. However, building static configuration runs into very strange problems.
First of all, the build log for "CEGUIBase-0_Static" reads the following:

It does build, yes, however, when building "CEGUISampleFrameWork-0.8_Static" gives an error:

The functions it can't find are all defined in FormattingSetting.cpp, which in the previous step reports to contain no new public symbols, thus it seems like it just doesn't get linked into the library. And I have absolutely no idea as to how to resolve this issue. Has anyone else experienced that?

UPD: I have tried forcing the compiler to include the FormattingSetting.obj in the library anyway, by adding the following code:

Now when compiling the Base library the LNK4221 warning went away. However, the error with unresolved symbol is still there, and it is impossible to build the samples framework statically.

The most confusing part is that the unresolved functions seem in fact to never be called in the files mentioned.

UPD: Looks like the functions defined in FormattingSetting.cpp are misplaced. When moved to FormattingSetting.h the static configuration compiles fine.
Now the interesting part. When running the statically built samples framework, I get the following error:

When debugging, I can see that when running the code

in HelloWorld.cpp, the ms_Singleton is in fact 0x0. Which it obviously shouldn't be. And in dynamic configuration it isn't. So what's wrong with it in static configuration? Any ideas anyone?

Hello. Sorry for the "me too" post but I also have the exact same problem that Basilio has and it's preventing me from updating to 0.8, as I need a MT build. Any pointers would be greatly appreciated.

Hi,
I am still investigating after bumping into problems while trying to use CEGUI both in dll's and main exe, but I strongly suspect
the following:
in microsoft visual c++ ( not in linux I think), you often get problems when trying to use both in main program and dll's a template ( here the singleton)
with a static member ( here ms_singleton).
The problem - and the solution- depends on how the template code is split between .h ( where a template is usually 100% coded) and specializations of the template , which apparently need to be defined in a separate .cpp file THAT IS PART OF ONLY ONE PROJECT ( one of the dll's or main) and made available to other projects ( like using __declspec(..)). I have no solution yet to offer, so more "googling" is needed; hope it helps ( a bit) though.

If someone finds a solution for this we would be happy to incorporate it. At the moment no one of us developers uses static builds and no one regularly uses VS 2012. We recommend dynamic builds in general, however the static option should still work. This option is less tested by us due to the nature of static builds being more prone to create problems (such as this one) which makes them a nuisance to use in general which is why we recommend dynamic builds only on Windows.

Statical CEGUI 0.8.3 seems to work for me after hours of testing and bugfixing.
However there were quite some issues with it..

1) I ran into the same issue described here.
I had to change FormattingSetting.h from:

//------------------------------------------------------------------------//
virtual void writeXMLTagToStream(XMLSerializer& xml_stream) const
{
// This does nothing and needs to be specialised or overridden
}

//------------------------------------------------------------------------//
virtual void writeXMLAttributesToStream(XMLSerializer& xml_stream) const
{
// This does nothing and needs to be specialised or overridden
}

to

//------------------------------------------------------------------------//
virtual void writeXMLTagToStream(XMLSerializer& xml_stream) const;

//------------------------------------------------------------------------//
virtual void writeXMLAttributesToStream(XMLSerializer& xml_stream) const;

I'm not exactly sure why there is an empty implementation in the FormattingSetting.h,
because there is actually one in FormattingSetting.c for these 2 methods.


2) I had to follow this thread to fix another linker unresolved symbol error:
viewtopic.php?f=10&t=6473

3) It seems I needed these two additional MS libs:
dbghelp.lib
winmm.lib

4) I had issues with statical PCRE, I had to define "PCRE_STATIC" in preprocessor definitions of CEGUI solution projects just like in the PCRE projects, otherwise the PCRE in CEGUI was trying to link dynamically but I was providing static PCRE lib.

5) I ran into issues related to the fact the filename "String.h" of CEGUI conflicts somewhere, I had to rename it to "CEGUIString.h" and replace any includes.

I think that's it.
Good to have it written down somewhere.

These all seem to be easily fixable and I think we could incorporate those changes easily into CEGUI.

I assume 3) has to be looked into further because I am not sure why this is needed at all and how to edit cmake to add these libraries. The others seem like obvious fixes to me that shouldn't create any isssues on any other ends. However some might break the ABI/API so they cant go into v0-8. Maybe Kulik can comment on that.

Could you provide a pull request for 1,2,4,5 ?
Best separate each change into a separate commit. That would be great.

Pasting this here to avoid Ident's wrath!



All of these fixes seem like v0-8 material to me. Except 5), I think 5) is unnecessary and is only a problem if you set up your include paths wrong.

About 1+2)
I think these are fixes should be added to the cegui code if reviewed and OKed.

About 3)
dbghelp.lib is only required for Debug builds for me (and of course since I'm linking everything statically only when compiling my own project exectuable) - not the statical CEGUI libraries. So I don't think you can adjust cmake of CEGUI to fix this? You just gotta know about it when linking everything in your project. It's because of CEGUI's Exceptions.c/h and its call to UnDecorateSymbolName(..) from dbghelp.lib in CEGUI::dumpBacktrace

winmm.lib is required in debug+release build (again in my own exectuable where I link everything in) because of CEGUI's SimpleTimer.c/h and its call to timeGetTime() from winmm.lib.

I basically mentioned these two MS libraries, because they are not part of what is usually linked into by visual studio automatically/by default.

About 4)
This really gave me a lot of trouble. I think this should actually be fixed in the CMAKE of CEGUI by making sure the preprocessor directive "PCRE_STATIC" is set in case the static libraries of PCRE are used (just like it sets CEGUI_STATIC). No idea which modules/projects require it exactly, I've set it on all. I'm not sure if this only related to my static CEGUI build. Probably you have to provide this "PCRE_STATIC" preprocessor directive even when building shared CEGUI against static PCRE? I can remember having issues with linking static PCRE also when building shared lib CEGUI in the past, then giving up and using shared pcre.

About 5)
Yes. I was wondering also why this happens, since MOST of the CEGUI files include String.h with subpath like "..CEGUI/String.h". But if I remember correctly there are a few in the subfolders which refer it as "../../String.h" or something like that, but I'm still not exactly sure why I had this issue. I might investigate it a little bit further. Obviously the current name follows its scheme and I'm not encouraging you to break it/rename it to CEGUIString.h, but it might be a good hint for someone running into issues and reading this.

Hi!
Here is my patch for cegui 0.8.3+vs2013+static linking.
Maybe its useful for someone.
http://pastebin.com/HdM9h4zK

Nice!

I forgot another thing to mention:
When linking everything statically into your project, make sure to also give the preprocessor directives:
CEGUI_STATIC

And in case you're using PCRE statically also:
PCRE_STATIC