CEGUI (Crazy Eddie's GUI) Forums

I did a search and found some stuff but couldn't figure out what is happening.

First off I got CEGUI working with the engine I'm using via the dll's. All that worked great. So now I'm trying to statically link to remove all those nasty dll's. I do have CEGUI_STATIC defined as well:



Here are the files I'm linking to on the Release build:


So I basically took the dll names that I was using and linked the _Static and \static\ libraries. So with the non static libraries of the above and having the dll's it worked. Changing to the static libraries and removing the dll's I'm getting the following linker errors.

As mentioned in the other thread, this will be because the static dependencies are built with the /MT and /MTd runtime options, though the CEGUI dll and such will be using the /MD and /MDd options. You might end up having to recompile the dependencies - unless you are only needing a specific subset. Meaning if you just want rid of the SILLY dlls and such, you would just need a customised build of SILLY and a tweak to the SILLYImageCodec project - the other 'required' deps such as freetype and pcre are already static for DLL builds, as it the expat parser.

Also, when statically linking CEGUI you need only specify one XML parser lib

CE.

Is there a VS setup for SILLY? I see this has some dependencies of some jpeg/png lib? This rabit hole is deep

SILLY uses premake for MSVC++ solution creation, so just run the premake.exe (you can use the one from CEGUI) in the root SILLY directory - as an aside, does the source package not contain the solution?

For the dependencies, you can either grab a copy of the SILLY dependencies from the same download page (or use this link: http://prdownloads.sourceforge.net/cray ... p?download) - note that these versions are a bit old now, but don't use the ones in the CEGUI dependencies, as they're linked with /MT and /MTd.

CE.

SILLY uses premake for MSVC++ solution creation, so just run the premake.exe (you can use the one from CEGUI) in the root SILLY directory - as an aside, does the source package not contain the solution?

hmm, I did run the premake that was in the SILLY dir but it didn't work. It just closes really fast and I can't seem to see any errors. I also did not see any MSVC++ solution with SILLY either.

So since premake wasn't working for me I just created an empty static library project. I added all the .cpp files and added the .h directory. I then added the jpeg, png, & zlib libraries. I have 1 error and not sure what to do about it.



Any ideas?

In regards to the msvc runtimes you need to decide if you want to distribute the msvc runtimes along with your software (/MD) or if you want to also statically link the msvc runtimes (/MT). Basically, each project needs to be compiled with the same msvc runtime configuration. The new precompiled static dependencies all use /MT (afaik); where as the new precompiled dll dependencies all use /MD (afaik).

In regards to SILLY, I suggest you figure out how to open a command shell/prompt (eg start->run->cmd.exe) from which you can run premake and see it's output without having it "close really fast." Premake will create a project for you with the necessary dependencies and precompiler necessary for compiling. Of course if you change your projects msvc runtime configuration to /MT and link to the new precompiled static libraries, you can avoid having to build all of the dependencies from source...in theory (I haven't actually tested the new packages myself).

Of course if you change your projects msvc runtime configuration to /MT and link to the new precompiled static libraries, you can avoid having to build all of the dependencies from source...in theory (I haven't actually tested the new packages myself).

I guess I thought that's what I was doing. hmm

Oh I see. If I change my project to /MT then all msvcprt.lib errors go away and all that is left are:



So I'm guessing I would need to recompile those static libs with /MT as well? When I download the source it looks like these are already setup as /MT. So why would I still get unresolved external symbol errors?

No, no, these are just missing libs All you have to do is ensure you link the ones from the static directory in the deps (where applicable).

timeGetTime is a Win32 function and is in winmm.lib

the FT_ ones are freetype: freetype.lib (freetype_D.lib in debug)
the glu ones are from the GL utility lib: glu32.lib
the png and jpg ones need: libpng, jpeg and zlib (libpng_d jpeg_d and zlib_d in debug).

CE.

Cool, I got this working in an exe. So my next steps will be to make my own dll and statically link all these dependencies into it, and then all the users of this engine should need is the includes, my lib, and the dll and it should be good to go! They will be excited for sure. Thanks for your help on this guys.

Rick

So maybe I'm thinking about this the wrong way. I don't have much experience with making dlls/libraries in C++.

My plan was to compile statically CEGUI into my own custom dll. So I created this custom dll project, and statically linked the parts of CEGUI I need. That worked all fine. I got a dll and a lib file from that. Now it's my understanding that because I statically linked the cegui libraries that my dll now has all that library code inside of it. Meaning that if I was to use this new dll I made I wouldn't have to add any other libraries to a new exe project but this new dll .lib file that comes with it and this would work? I assumed it would still require the header files, but the .lib files of cegui should all be compiled in my dll right?

When I do this and just create my class object that I created in my dll I get:
1>CEGUITest.obj : error LNK2001: unresolved external symbol "public: __thiscall LECEGUI::~LECEGUI(void)" (??1LECEGUI@@QAE@XZ)
1>CEGUITest.obj : error LNK2001: unresolved external symbol "public: __thiscall LECEGUI::LECEGUI(void)" (??0LECEGUI@@QAE@XZ)

Which tells me that the .lib to my dll doesn't seem to be working.


Am I thinking right here or am I way off base on how this works?

For a DLL you need to apply code that controls whether symbols are imported or exported. Generally this is done using a preprocessor macro system. For example, a simplified version of how we do that in CEGUI is:


You then use 'CEGUIEXPORT' with functions and classes to automatically import/export as appropriate according to whether you're building the DLL itself - in which case we define CEGUIBASE_EXPORTS - or building client code of the DLL, in which case you do not define CEGUIBASE_EXPORTS.

To import/export a function:


To import/export a class:


Btw, don't use that construct above vertabim - change the macro names to something appropriate for your project - otherwise there will be conflicts as we use those in CEGUI

HTH

CE.

I actually did that, but now that I think about it, always best to sleep on an issue , I didn't do that on the constructor/destructor functions. I'm guessing that's it! I didn't use a macro for the export/import I just typed it out

OK, so that worked. I can now use my class and it's methods. But when I try to put CEGUI specific code into the exe program I get linker errors about the missing functions. My assumption is that since I statically linked the CEGUI stuff into my own DLL, that my DLL's lib file would have these in there also, but it's not looking like that. I assume the static libraries for CEGUI don't have the __declspec(dllexport) on them so they won't be in my dll's lib file right? Is there some macro or something that I can set so that the CEGUI stuff when compiled into my dll will also be available for usage in an exe project? I don't wish to encapsulate all of the CEGUI stuff, just some. For creating widgets and such I still wish for the user to use normal CEGUI classes.

So it's like I want CEGUI to be statically linked into my DLL but still exposed through my DLL.