CEGUI (Crazy Eddie's GUI) Forums

Hello,

I am currently integrating CEGUI v0.7.1 into my OpenGL application and I am running into some difficulties with the final linking process on my application side.


CEGUI is able to make and install with no problems in a static configuration using the following configure line:

As you can see the CEGUI_FALAGARD_RENDERER, CEGUI_WITH_XERCES, and CEGUI_CODEC_FREEIMAGE defines were added on top of the required CEGUI_STATIC define and passed into the LDFLAGS for CEGUI's configure to force the inclusion of those module's header files based on the #ifdef statements in cegui/src/CEGUISystem.cpp file (e.g. #include "XMLParserModules/XercesParser/CEGUIXercesParserModule.h)

This generates the following static libraries:

libCEGUIBase.a
libCEGUIFalagardWRBase.a
libCEGUIFreeImageImageCodec.a
libCEGUIOpenGLRenderer.a
libCEGUIXercesParser.a

NOTE: The required libraries (FreeImage v3.13.1, PCRE v8.10, and wxWidgets v2.8.11) for building CEGUI in this configuration were also built statically

Running strings and nm on libCEGUIFalagardWRBase.a, libCEGUIFreeImageImageCodec.a, and libCEGUIXercesParser.a show that the undefined reference to XXX mentioned in the first code block exist in the static library


... a similar result exists for createParser, destoryParser, destroyImageCodec, and createImageCodec when checking them against the libararies libCEGUIFreeImageImageCodec.a and libCEGUIXercesParser.a

Here is the linking line of my application:

I show this only to indicate that the libraries and the library locations exist during the link step, which based on strings and nm make the undefined references that much more confusing.

I have also tried the same configure and build process using the latest version of CEGUI in subversion (r2577) and the same undefined references exist there too. This only seems to be an issue when trying to statically link my application with CEGUI and does not exist when CEGUI is configured to create shared objects for runtime loading.

Some other information that might be useful:

RedHat Enterprise Linux 4
g++ version is 3.4.6
32-bit architecture

Any information or suggestions would be greatly appreciated!

I think it has to do with the order the libraries are specified, you need to ensure that libs appear before any other libs that they depend on (so mainly in this case, that CEGUIBase.a appears before the image codec and xml parser libs).

It will probably interest you to know that while static libs were not officially supported in 0.7.1, they will be in the next release - so you'll be able to just say '--enable-static --disable-shared' and not have to worry about the additional defines and such

HTH

CE.

CrazyEddie wrote:I think it has to do with the order the libraries are specified, you need to ensure that libs appear before any other libs that they depend on (so mainly in this case, that CEGUIBase.a appears before the image codec and xml parser libs).

Thanks for the quick reply CE ... I assumed the order was the issue as well, but moving them around to be in dependency order (CEGUIFreeImageImageCodec.a CEGUIXercesParser.a CEGUIFalagardWRBase.a CEGUIOpenGLRenderer.a CEGUIBase.a) didn't fix the issue either. I had also assumed that that maybe the extern "C" in the 3 modules for the 5 method definitions that are coming up as undefined references was the issue, but strings and nm proved that to not be the case as the methods were not being mangled with g++ compilation.

CrazyEddie wrote:It will probably interest you to know that while static libs were not officially supported in 0.7.1, they will be in the next release - so you'll be able to just say '--enable-static --disable-shared' and not have to worry about the additional defines and such

That will be nice to see in future releases!

I think the order should be largely reversed:
CEGUIOpenGLRenderer.a CEGUIBase.a CEGUIFreeImageImageCodec.a CEGUIXercesParser.a CEGUIFalagardWRBase.a

Basically, CEGUIBase contains references to those functions, so the libs containing them must appear afterwards. If it still does not work, I'll have to run a test myself

CE.

Still a no go ... The odd thing is this is not an issue when building CEGUI with the shared objects and dynamically loading the modules.

Ok, thanks for the information. I'll run a test of my own with the 0.7.1 code, a configure line based on yours, and see if i can reproduce the results

CE.

CE,

I noticed that the new v0.7.2 has been released and saw the following bug fix:


I decided to revert back to a static build and test with the latest release ... same issues still exist. I am not sure if you have had any time to attempt to reproduce the results, but I figured I would check back in and see if you had any other thoughts.

Ok, first an apology, since it appears that I never did test things specifically for your issue I'm adding a ticket to mantis this morning so that this will not get forgotten again.

However, I did test somewhat when I made fixes that resulted in that change log entry, and static linking was working - at least at that point

I'll report back soon. If you don't hear anything in a week to 10 days, bump this to remind me

CE.

hi there,
i have the same problem but using ms vs2010. (still using cegui 0.71)
if i link it as dll all workes fine.
if i link it as lib it gets linked - fine on the first look (warning lnk4221). but if i link my program using it i get link errors: (LNK2001), LNK2019.
for example (of course depending on what funktion i use at what point of code):


i analysed the symbols in the libs for dll and static linking.
the method getMessage was realy missing in the static linked one.
after that i analysed the exceptions.obj file - again missing method if i link statically (but method was in it)

so i watched the code and now i have found the problem!
the functions not linking in static are written like this:

i think the compiler treats them for inline (even when inline is strictly forbidden) or just don't use it because nobody is using it or what ever.
solution: put method body in the cpp file -> after that this function seams to work also statically linked...

i'm not sure if it's a error in compiler/linker or defined that way in the standartisation.
but it's strange that it is working with dynamically linked.

hope you will release a fix soon - i don't want to change all that functions on my own^^

I don't think you have the same issue, since the static build on Win32 gets tested a lot more (not only by me, but by others using it every day).

Your error message here:


Tells me that you're compiling your app without CEGUI_STATIC defined. For static linking, you must define CEGUI_STATIC for all files and components that will be linked - the best place to do this is in the preprocessor macros for your MSVC++ projects.

HTH

CE

PS. Note to OP. I will be testing the linux issue, definitely, 100% guaranteed - tomorrow! And I'll report back then.

hi,
ok maybe it's a different problem and maybe it's only at my side.
i thougth it's maybe the same because of the error type and the functions we call.

i was running premake to set up the projects for vs2008 and than opening it with vs2010 so the project gets updated to vs2010.
in the project are compiling configurations one of them for compiling as "debug_static".

i checked the define twice! it is there and workes correct!

i also tryed with vs2008 compiler/linker/libs (inside of vs2010 you can change this on the projects general options page).
i got the same problem.

it seams like the main parts of the lib are linked correct. and using the "debug" configuration all of it is linking correct - and my app is working.
just with static linking it seams to make a difference only with methods that have the body direct in the header and not in the cpp file!
(yes i made a config for static linked libs in my app - and it realy should be configured right way and should work as far as i can see.)
i changed localy the described method in the source to have the body in the cpp - after that this error was gone and the method was in the object file and in the lib (analysed as i said).
so i realy don't think it's kind of a config problem or something like that.

edit:
maybe it's a new problem with vs2010.
maybe because of the changes with C++0x in vs2010.
maybe only with newer compiler/linker generations of vs versions.
maybe something else.

@fero:
I today got around to testing static support in 0.7.2. This was tested using a set up as far removed from the regular CEGUI samples set up as I could get, in order that nothing 'special' got picked up from there. My CEGUI for the test was built with the following configure line:

And subsequently the files were installed to the location mentioned above.

I made a test app, which basically sets up an X11 window with GL context, and started up the CEGUI system and created a test CEGUI window (i.e. the code from the tutorials).

I built my test app with the following command:


My test app builds and runs successfully The only, maybe major, difference I see is that I use gcc 4.4.3, though to be honest I wouldn't have thought a compiler issue would have caused issues at this point, and doing something so basic as linking. It seems your own configure and build lines contain a bunch of defines and such that mine do not, so I would begin by trying to get as close to the above as you can.


@DEvil HUnter:
I tested the static build on MSVC++ 2010 via the samples that come with the SDK for the same, though I was careful to ensure I modified the code I built to reference the specific symbol that you've reported issues with. Aside from a minor glitch in the freeglut lib in the dependencies (related to the fact I forgot to remove the idiotic use of #pragma to link libs), there were no issues, and definitely no unresolved symbols at link time.

I will reiterate my reply from earlier. The fact that the error mentions '__declspec(dllimport)' means that the symbol / class has that attribute specified for it. As we clearly can see here (from CEGUIBase.h):

When CEGUI_STATIC is defined, that attribute is not - indeeed, can not - be associated with the CEGUIEXPORT macro which controls how symbols are imported or exported from DLLs.

I was unable to tell from your post whether you checked the CEGUI library projects or your own app's project for the macro. Obviously it exists in the static builds for the CEGUI library projects, it's your own project that needs to define the macro, so if you did not already check that (as I say, it was not clear from your post precisely what you checked).

CE.

hi,
i apologise. i missed to add the precompiler define in one sub projekt (my error handler). thougth main project would be enought
now it seams to working.

btw why do i need to add some libs in main project for silly image and stuff?
is it still using silly as dll - even if i build cegui stuff with static?

much thanks and again - apologise

DEvil HUnter wrote:btw why do i need to add some libs in main project for silly image and stuff?
is it still using silly as dll - even if i build cegui stuff with static?

There are two versions of the dependencies (which I'll cover in your other post ), but when using the 'static' versions of the dependency libraries, no you will not be using the SILLY.dll or indeed any other DLL.

If you don't know why you need to link the final .exe in your project with all the dependent libraries for a static build, then you should do some research on exactly what static linking is and how - and why - it differs from dynamic linking. Basically, though, a static library is just an archive of compiled .o or .obj files, and generally speaking you do not / can not link other libraries to a static library (which is why there's normally no 'linker' settings in MSVC++ for static libs). This means that when you eventually link your final .exe you need to make sure that all referenced symbols are available for resolution by the linker - and that means you need to link to all libs and their dependent libs right the way down.

CE.

CE,

Thanks for looking into this. I will experiment some more in the next couple weeks to try and narrow down what is causing the problem (autotools, gcc, ld, ...etc). Once (if) I come up with a solution to my problems I will post that information here.