CEGUI (Crazy Eddie's GUI) Forums

Hello!

I'm trying to build CEGUI for 64-bits plateforms, and I've read from previous posts that it's not easy.

I managed previously to build a 32-bits version of CEGUI.
So I duplicated the solution (Visual Studio 2008), into a new one that I use for 64-bit.

The compilation process of CEGUI worked perfectly in 64-bit from Visual Studio 2008, by just copying the 'x64' option from the 'Win32' in the configuration manager.

The problem is when the compiler needs to link against the dependencies.
I've tried to recreate the dependencies folder that I've downloaded and used for 32-bit compilation.
I compiled in 64-bit these libraries from their sourcecode I've downloaded from the web: lua, freetype, zlib and pcre

PCRE give me a linking problem that I am trying to solve for 2 days:


But pcred.lib is present in my dependencies folder .if I remove it, Visual tell me :


And the dumpbin utility of Visual Studio show me that the pcred.lib contains a ''pcre_free'' symbol.

Does somebody experienced the same problem?


A few more doubts about the subject:

1) In the configuration list, there is

• Debug
• Debug_Static
• Release
• Release_Static

Debug and Release generate a ".dll" and a ".lib" with dynamic links to the other libraries (lua, pcre, freetype ...)
Debug_Static and Release_Static generate a ".dll" and a ".lib" that contain the code of the extra libraries (lua, pcre, freetype ...)
Is it right?

2) The ''dependencies'' folder contains:

• /bin
• /lib/dynamic
• /lib/static

/bin contains '.dll' of librairies that contain the code of other libraries
/lib/dynamic contains '.lib' of librairies that uses links to other libraries
/lib/static contains '.lib' of librairies that contain the code of other libraries
is it right?

3) Another thing I wonder
CEGUI is LGPL, and I've read somewhere on the wiki that we can only use it with dynamic linking.
So normally the ".lib" versions should be useless, right?


Thanx in advance for your help

Found a solution:
A new version of PCRE has been released, and it seems to works now with it, and I don't have no more th e problem of "missing symbol"
The version is 8.21.

I 've generated the Visual Studio project with CMake, and then compiled and got the 2 files i needed: pcre.lib and pcre_d.lib

I know you already have this compiling; congrats on that. Just wanted to clarify a few things.

matt wrote:PCRE give me a linking problem that I am trying to solve for 2 days:

Code: Select all

error LNK2001: unresolved external symbol pcre_free

But pcred.lib is present in my dependencies folder .if I remove it, Visual tell me :

Code: Select all

LINK : fatal error LNK1104: cannot open file 'pcred.lib'

And the dumpbin utility of Visual Studio show me that the pcred.lib contains a ''pcre_free'' symbol.

Does somebody experienced the same problem?

As you figured out, you needed use a newer version of PCRE that is 64-bit compatible. Another alternative would have been to disable PCRE using the build-configuration script for your platform. As far as I know, every dependency-library can be disabled; obviously you would also lose features that are reliant on a disabled library.

1) In the configuration list, there is

• Debug
• Debug_Static
• Release
• Release_Static

Debug and Release generate a ".dll" and a ".lib" with dynamic links to the other libraries (lua, pcre, freetype ...)
Debug_Static and Release_Static generate a ".dll" and a ".lib" that contain the code of the extra libraries (lua, pcre, freetype ...)
Is it right?

The Debug_Static and Release_Static configurations do not generate ".dll" files. They generate ".lib" files that already contain the code from the external dependencies. **

2) The ''dependencies'' folder contains:

• /bin
• /lib/dynamic
• /lib/static

/bin contains '.dll' of librairies that contain the code of other libraries
/lib/dynamic contains '.lib' of librairies that uses links to other libraries
/lib/static contains '.lib' of librairies that contain the code of other libraries
is it right?

The non-static (Debug/Release) build generates the CEGUI DLLs by dynamically linking to libraries in /lib/dynamic, and requires your application to load all of the DLLs in /bin at runtime. The static (Debug_Static/Release_Static) build generates CEGUI LIBs by statically linking to libraries in /lib/static, and only requires your application to link to the generated CEGUI LIBs at compile time. Basically, the static-version contain code from other libraries, the dynamic libs do not and so need external DLLs to accompany the application. **

3) Another thing I wonder
CEGUI is LGPL, and I've read somewhere on the wiki that we can only use it with dynamic linking.

That information is out of date. CEGUI has used the MIT License from at least version 0.6 and newer. There may be some external dependencies that use LGPL but from my experience you can build CEGUI using solely MIT-compatible dependencies.

** Note that I am assuming the build configurations are still the same from v0.7.1.

Thanx jamarr for all these explanations!

I'm about to have the x64 compiled and working. If so, I can post my bundle of dependencies somewhere on the CEGUI site

I managed to compile all subprojects (CEGUIBase, CEGUICoronaImageCodec etc.) in Debug/Release/StaticDebug/StaticRelease,
except a problem compiling CEGUIFreeImageImageCodec.lib and CEGUIDevILImageCodec.lib in Debug and Static

The unresolved external symbol error is pretty common. It basically means that the linker cannot find the symbol in any of the .lib files you have specified. It looks like there is a function in FreeImage and DevIL that cannot be looked up for some reason. The most typical scenarios are 1) user did not pass the .lib to the linker or 2) user did not pass the proper build of the .lib to the linker.

Usually a failure to follow #1 is followed by many symbol errors since the linker will fail to find all symbols used from that library.

If you attempted to build the proper version of the .lib and have properly passed that .lib to the linker, then the next most likely cause is that the .lib no longer exports that symbol. This is most likely caused by using a newer version of the library that no longer exports the symbol. It could also be that the x64 build for the library does not export the symbol, but that seems less likely.