Link errors with PCRE lib (Win32 + static build)

[Valentin Perrelle]

The building fails when building libCEGUIBase.dll :

Code: Select all

Linking CXX shared library ../../bin/libCEGUIBase.dll
Creating library file: ../../lib/libCEGUIBase.dll.a
CMakeFiles/CEGUIBase.dir/objects.a(PCRERegexMatcher.cpp.obj):PCRERegexMatcher.cp
p:(.text+0xa8c): undefined reference to `_imp__pcre_free'
CMakeFiles/CEGUIBase.dir/objects.a(PCRERegexMatcher.cpp.obj):PCRERegexMatcher.cp
p:(.text+0xb00): undefined reference to `_imp__pcre_free'
CMakeFiles/CEGUIBase.dir/objects.a(PCRERegexMatcher.cpp.obj):PCRERegexMatcher.cp
p:(.text+0xbde): undefined reference to `_imp__pcre_exec'
CMakeFiles/CEGUIBase.dir/objects.a(PCRERegexMatcher.cpp.obj):PCRERegexMatcher.cp
p:(.text+0xdf6): undefined reference to `_imp__pcre_free'
CMakeFiles/CEGUIBase.dir/objects.a(PCRERegexMatcher.cpp.obj):PCRERegexMatcher.cp
p:(.text+0xe44): undefined reference to `_imp__pcre_compile'
CMakeFiles/CEGUIBase.dir/objects.a(PCRERegexMatcher.cpp.obj):PCRERegexMatcher.cp
p:(.text+0xfca): undefined reference to `_imp__pcre_free'
collect2: ld returned 1 exit status
make[2]: *** [bin/libCEGUIBase.dll] Error 1
make[1]: *** [cegui/src/CMakeFiles/CEGUIBase.dir/all] Error 2
make: *** [all] Error 2

The error seems to come from cmake/FindPCRE.cmake line 14

Code: Select all

    set( PCRE_DEFINITIONS_STATIC "PCRE_STATIC" CACHE STRING "preprocessor definitions" )

should probably be

Code: Select all

    set( PCRE_DEFINITIONS "PCRE_STATIC" CACHE STRING "preprocessor definitions" )

I don't know anything about cmake but in comparison with other find*.cmake it seems more suitable (and more relevant regarding the next line) and it suceed to build the library.

[CrazyEddie]

Hi,

Can you confirm which dependency pack you are using?

The current default branch code is set up to build against our source based dependency pack (current version is version 0.8.x-beta6). For the dynamic build of CEGUI we're now using a dynamic pcre (and other) libs, and the cmake 'find' modules should work ok with those (but, I will admit I have not tested the static build in quite a while).

If you are using the source based dependency pack, and still have this issue with the dynamic build, I will raise a ticket as it means something (else) is definitely broken

Thanks,

CE.

[Valentin Perrelle]

I'm using the prebuilt dependencies for CEGUI 0.7. With my fix they work fine : the dynamic version of cegui is built against dynamic version of the dependencies and the static one with static libraries. I'll give you the surrounding code, maybe it will be more explicit :

Code: Select all

if (WIN32 OR APPLE)
    find_library(PCRE_LIB_STATIC NAMES PCRE pcre libpcre PATH_SUFFIXES static)
    find_library(PCRE_LIB_STATIC_DBG NAMES pcre_d libpcre_d PATH_SUFFIXES static)
    set( PCRE_DEFINITIONS_STATIC "PCRE_STATIC" CACHE STRING "preprocessor definitions" )
    mark_as_advanced(PCRE_LIB_STATIC PCRE_LIB_STATIC_DBG PCRE_DEFINITIONS)
endif()

I understood you are compiling on Linux system so you'll never test this part. I don't know what it does, but obviously, it can't be PCRE_DEFINITIONS_STATIC set and PCRE_DEFINITIONS marked as advanced. It should be the same variable, and that's how it's done in other find*.cmake files.

[CrazyEddie]

Hi,

The 0.7.x prebuilt dependencies are not 100% compatible with the default branch code and build system (some are missing and others are built using incompatible configurations. For this reason the 0.7.x dependencies are only officially supported for use with the 0.7 release series).

The reason that the PCRE_STATIC definition is specified in PCRE_DEFINITIONS_STATIC is because when using the intended dependency pack, pcre is only built as a static lib for linking the static CEGUI build; when linking the dynamic cegui build, the pcre lib is now a DLL, so having PCRE_STATIC set in PCRE_DEFINITIONS would be incorrect in that case.

CE.

[Valentin Perrelle]

The reason that the PCRE_STATIC definition is specified in PCRE_DEFINITIONS_STATIC is because when using the intended dependency pack, pcre is only built as a static lib for linking the static CEGUI build; when linking the dynamic cegui build, the pcre lib is now a DLL, so having PCRE_STATIC set in PCRE_DEFINITIONS would be incorrect in that case.

That didn't change between 0.7 and 0.8. static CEGUI is linked against static libs and dynamic CEGUI is linked against dynamic ones. What i am saying is that your CMake is not doing that : he is trying to compile dynamic version of cegui against static version of pcre. Look at the log above, gcc doesn't find the symbols from dynamic library because cmake gave him the static one.

[CrazyEddie]

That didn't change between 0.7 and 0.8.

I'm sorry. I thought I knew what had changed between 0.7 and the current unstable, since you know, I err, did all the work related to it If you're going to post with such arrogance, best be sure you are right, otherwise you just end up looking like a complete fool. Alas, that is what has happened here.

I'm going to go over this one more time, in the hope that you might just be able to grasp what I have been trying to say. And yes, now I am being a complete dick - and that's what happens when the likes of you come here and post in the way you have - apparently not to receive support, because you totally ignore what you're told and continue on with your own incorrect assumptions, and then continue to wonder why things are not functioning correctly. If you're not going to listen to what you are told, why even bother to come here?

In 0.7 we used a static pcre and a static freetype even when linking the dynamic CEGUIBase library - you can confirm this yourself by looking in the 0.7.x dependency package: there is no DLL for those two libraries (unless we use magical fairy DLLs that are invisible to the naked eye, or something). This has most definitely changed in the current unstable - I know this with 100% certainty, because I am the one who changed it - do not ever come here again and tell me what has or has not changed - it will not go well for you. I should also state that I have, in fact, compiled the unstable code on all three supported platforms multiple times (more recently, just the dynamic build - which is what you're reporting an issue with here) and have not seen this issue at all. So I know with 100% certainty that for a dynamic build, the set up of dependencies on Windows and on Mac OS X is absolutely, 100% correct - but you must use the correct dependency pack, which is not the 0.7.x dependency pack.

My first reply said:

The current default branch code is set up to build against our source based dependency pack (current version is version 0.8.x-beta6).

My second:

The 0.7.x prebuilt dependencies are not 100% compatible with the default branch code and build system (some are missing and others are built using incompatible configurations. For this reason the 0.7.x dependencies are only officially supported for use with the 0.7 release series).

I don't take kindly to wasting my time with people who do not take the advice they are given.

In case you still have not got it, I will reiterate again - you can not use the 0.7 dependencies with the unstable code in the default mercurial branch, you must use the source based 0.8.x-beta6 dependencies that were created for this purpose.

Right about now, after one of my rants, the typical thing is that I am apologised to for any 'offence' - well, I will pre-empt that by saying you have not offended me at all, but you have completely enraged me, and I'm not interested in any apology you might offer. In future, read the responses you are given and act on them.

CE.

[Valentin Perrelle]

Ok. I just didn't understand what you said. I still don't. And i can't make it fit with what i observe.