Codeblocks,cegui 0.8.x dependencies and problems

[Jefferian]

Heh, obviously there would have been problems.
I've downloaded the most recent version of cegui and its dependencies. Also, the most recent version of CMake.
Obviously i had to start with the dependencies.
Configuring the project for mingw - codeblocks and generating it isn't a problem.
Building it, well, that's another matter.
I'm getting some syntax errors in the libexpat.def file. Some errors i can comprehend quite logically, especially since it is clearly written those instruction should have been used by another compiler...

Code: Select all

; DEF file for MS VC++

LIBRARY
EXPORTS
  XML_DefaultCurrent @1
  XML_ErrorString @2
  XML_ExpatVersion @3
  XML_ExpatVersionInfo @4
  XML_ExternalEntityParserCreate @5
  XML_GetBase @6
  XML_GetBuffer @7
  XML_GetCurrentByteCount @8
  XML_GetCurrentByteIndex @9
  XML_GetCurrentColumnNumber @10
  XML_GetCurrentLineNumber @11
  XML_GetErrorCode @12
  XML_GetIdAttributeIndex @13
  XML_GetInputContext @14
  XML_GetSpecifiedAttributeCount @15
  XML_Parse @16
  XML_ParseBuffer @17
  XML_ParserCreate @18
  XML_ParserCreateNS @19
  XML_ParserCreate_MM @20
  XML_ParserFree @21
  XML_SetAttlistDeclHandler @22
  XML_SetBase @23
  XML_SetCdataSectionHandler @24
  XML_SetCharacterDataHandler @25
  XML_SetCommentHandler @26
  XML_SetDefaultHandler @27
  XML_SetDefaultHandlerExpand @28
  XML_SetDoctypeDeclHandler @29
  XML_SetElementDeclHandler @30
  XML_SetElementHandler @31
  XML_SetEncoding @32
  XML_SetEndCdataSectionHandler @33
  XML_SetEndDoctypeDeclHandler @34
  XML_SetEndElementHandler @35
  XML_SetEndNamespaceDeclHandler @36
  XML_SetEntityDeclHandler @37
  XML_SetExternalEntityRefHandler @38
  XML_SetExternalEntityRefHandlerArg @39
  XML_SetNamespaceDeclHandler @40
  XML_SetNotStandaloneHandler @41
  XML_SetNotationDeclHandler @42
  XML_SetParamEntityParsing @43
  XML_SetProcessingInstructionHandler @44
  XML_SetReturnNSTriplet @45
  XML_SetStartCdataSectionHandler @46
  XML_SetStartDoctypeDeclHandler @47
  XML_SetStartElementHandler @48
  XML_SetStartNamespaceDeclHandler @49
  XML_SetUnknownEncodingHandler @50
  XML_SetUnparsedEntityDeclHandler @51
  XML_SetUserData @52
  XML_SetXmlDeclHandler @53
  XML_UseParserAsHandlerArg @54
; added with version 1.95.3
  XML_ParserReset @55
  XML_SetSkippedEntityHandler @56
; added with version 1.95.5
  XML_GetFeatureList @57
  XML_UseForeignDTD @58
; added with version 1.95.6
  XML_FreeContentModel @59
  XML_MemMalloc @60
  XML_MemRealloc @61
  XML_MemFree @62
; added with version 1.95.8
  XML_StopParser @63
  XML_ResumeParser @64
  XML_GetParsingStatus @65


Mh, what to do? I may avoid codeblocks and try building the dependencies with mingw itself (if i had any idea about how to do that...that was the first thing i tried to do, especially since i built ogre via mingw as well, but there was quite a comprehensive step-by-step tutorial there). But other than that...i don't know what to do. I can't say to be experienced regarding building libraries from source...

[Basilio]

Ran into the same problem. As far as I understand, there is an error in cmake files for libexpat and libpng.
There is a file called list.txt in the build\src\libpng-1.4.7\CEGUI-Build\CMakeFiles\libpng.dir, build\src\libpng-1.4.7\CEGUI-Build\CMakeFiles\libpng-static.dir, build\src\expat-2.0.1\CEGUI-Build\CMakeFiles\expat.dir, and build\src\expat-2.0.1\CEGUI-Build\CMakeFiles\expat-static.dir.
The last line of these files looks something like this:

Code: Select all

g:\mingw\bin\gcc.exe ..\..\..\..\..\src\expat-2.0.1\lib\libexpat.def -shared -o ..\..\..\dependencies\bin\libexpat_d.dll -Wl,--out-implib,..\..\..\dependencies\lib\dynamic\libexpat_d.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles\expat.dir/objects.a -Wl,--no-whole-archive -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32


I might be totally wrong, but I suppose that trying to link a .def file with the help of gcc is not right. So you have to manually remove the first argument (with the path to .def file) from all four list.txt files. This seems to resolve the issue.

[Jefferian]

Thank you very much for the help. It seems that the issue wasn't exactly identical - i had no list.txt files, but they were called link.txt instead and there were just two of them. Removing the argument solved that issue.

Then i got another issue regarding directx11. I lacked a file that isn't usually used with MinGW, as it seems, so i had to add it manually (strsafe.h).
Now i'm getting lots and lots of errors in the DXGI.h file about the IDXGIObject interface while building D3D11Effects. Let's see what i can find about this...
Edit: Well, i hadn't found anything that could help, so i simply avoided to build those effects and i had no other problems. Gotta build cegui itself now.
Edit2: Mh, not yet. I did forget to make both debug and release versions of the dependencies. Gotta redo them.

[Jefferian]

And the problems go on, it would seem. I'm trying to build the debug version of cegui. Code:Blocks is kindly telling me i won't be able to.

Code: Select all

ld.exe||cannot find -lDbgHelp|
cegui\src\CMakeFiles\CEGUIBase-0.dir\build.make|4093|recipe for target 'bin/libCEGUIBase-0_d.dll' failed|
CMakeFiles\Makefile2|77|recipe for target 'cegui/src/CMakeFiles/CEGUIBase-0.dir/all' failed|
C:\cegui\building\cegui-debug\Makefile|135|recipe for target 'all' failed|

I have absolutely no idea what to do.

Edit: and assuming is it related to the dbghelp.dll, well, i have it. In the system folder, obviously.

[Jefferian]

Uh...any help regarding this? No one else ever encountered this issue?
I still haven't found a way to go on. Still at that 61% of the debug build.
I tried modifying the CMakeCache.txt file to try putting a direct path for that lib...but it gets reverted back whenever i try building.
Can't do much about that, i don't know how CMake works exactly. I never had to use it before - i simply used the SDK or followed tutorials step by step (like the one for 0.7.9) and luckily enough, they worked well.

[Kulik]

I do not use mingw so I can't offer much help.

I primarily use GNU/Linux distros to do development. When I really have to use Windows for some reason, I use Visual Studio Express. Any reason why you are not using that?

MinGW build *should* work but the support is unofficial and we aren't testing it as much. None of us in the CEGUI team use it as their primary dev env.

[Jefferian]

The main reasons are ease of use - i don't like Visual Studio's IDE - and, well...seems like converting a project from C::B to VS may be quite a mess.
Still, i guess i shall have to do it. You can't find official support for anything else than Visual Studio these days - and i'm not referring just to cegui.
And i can't afford to lose days and days over libraries i can't compile successfully. So, even if i don't like the IDE, guess i shall have to adapt.

[Kulik]

You can use whatever IDE you like and just use the MSVC toolchain.

[Jefferian]

Sure, i can try.
And then i get a lot of errors i can't even comprehend, since every related explanation on the internet directly refers to visual studio.
Same when compiling something. It is always supposed you're using both the compiler and visual studio together, so i would have those same problems anyway.
If i have to waste time anyway, better waste time with something that is supposed to work as it is, and use visual studio directly. Instead of wasting hours trying to solve problems and just getting angry because i can't even compile the dependencies.
And that is what i did in these hours. Getting angry and wasting time.

[Kulik]

Sure, if you need hand holding and tutorials, using Visual Studio IDE is your best bet.

On Windows I usually use nmake or jom if the project is big enough to warrant it. jom is a nmake clone able to build in parallel. You can also use msbuild.exe and just pass the project file AFAIK.

The compiler and linker errors will be EXACTLY the same. Visual Studio uses the exact same compiler and exact same linker as you would. It's just the way to set them up that's different.

[Jefferian]

Still, there was no problem building the dependencies with VS2012.
I'm still not able to build cegui itself - cmake doesn't seem to see the dependencies unless i manually put the path of all of them...and even so i've got some problems regarding ft2build.h later (the compiler couldn't find it, even if all was right while using cmake and the file could still be opened by manually putting the path in the related file).
Since i would rather build it cleanly, and i suspect that cmake not seeing the dependencies may be the cause of further problems later...is there any way to understand how/where i should place the dependencies? Should i change some system variable? Change some file i don't even know? I mean, i can see in the cmake gui a place where it asks for dependencies...but even putting the path to them there, nothing changed. Even reworking their folders - putting debug, release and include in the same dependencies subfolder, C:\cegui\cegui_mk2\dependencies - nothing changed.
I also tried following the guide here.
http://www.cegui.org.uk/wiki/index.php/ ... rom_source
But it doesn't actually explain anything, to be blunt.
The first time i tried using cegui, i surrendered cause i couldn't make it work. Then i found a good videotutorial after a year and i was finally able to use it. Now i'm at the same point of the first time - i spent more than a week and i'm still not able to do anything. Because i have no experience regarding building libraries and using cmake to build them, but it is magically supposed that everyone out there perfectly knows how to use such tools.
It is frustrating.

[Kulik]

https://www.youtube.com/watch?v=BxT_rggGSKE

Kudos to timotei who made this. And yes, it is assumed that people know how to build stuff, we are not here to teach you build system basics.

cmake has extensive documentation at http://cmake.org

[Jefferian]

Well, the video was useful at least. I'm using VS2010 now. Using the default setting apart from adding the ogre renderer and removing the directx11 one.
Compilation was fine and all, apart from having to manually add the boost directories to the include and library paths for the ogre renderer project.
Albeit, i'm still having a problem. The sample framework doesn't seem to work for me - it won't find the dependencies' dlls unless i put all in the bin folder, but i doubt it is the intended behaviour.
I also had to move the contents i've built back to cegui/cegui-0.8.2 and merge the directories, else either it complained cause it couldn't find some xml file (if i tried to use the sampleframework in the build directory) or it wouldn't work at all (if i replaced the contents of the cegui-0.8.2 directory with the ones in the build directory).
So...is this the default behaviour or there is something wrong?

[Kulik]

Regarding the first problem - copying DLLs. There are 2 ways around it, either you spawn an environment where $LD_LIBRARY_PATH (UNIX) or $PATH (Windows) is altered in such a way that the libs will be found. Or you specify a post build step a copy the dlls to your final destination. The first is obviously faster and less intrusive but it won't give you easily deployable files. I think you can specify this environment in Visual Studio, I recall finding this option somewhere in the Run/Debug properties. What I have said here is common knowledge and you will need it for all development with ANY libraries. This is not something we invented to torment our users.

I am not sure about Windows specifics of sample framework, the best person to ask is probably Ident. On Linux you have to pass the samples.xml file to the executable if it's not in the default post-install location.

[Jefferian]

Well, it was just to understand if it was being built correctly, cause the structure of the folders was different from the one i had in the 0.7.9 version.
Anyway, after that, i was having the same errors reported in this thread in my project.
http://www.ogre3d.org/forums/viewtopic.php?f=5&t=78139
Guess i'll use the prebuilt ones by Transporter, since i'm already switching to VS anyway. But thanks for the help so far.

Edit: guess i also found where is the problem - and Transporter's prebuilt ones won't solve this.
There is a string.h in CEGUI's include files. It gets used instead of the default string.h, and this causes a lot of problems.
(A similar case here: http://stackoverflow.com/questions/5319 ... -namespace)


Edit2: But i can see it was already been reported, and it is a design choice.
viewtopic.php?f=3&t=5954