CEGUI's OpenglRenderer with static dependencies

[Trigve]

Hi,
when trying to build the CEGUI OpenGLRenderer with the static dependencies (with CEGUI_BUILD_SHARED_LIBS_WITH_STATIC_DEPENDENCIES == true), I've got some unreferenced symbols from glew library. It looks like the GLEW_STATIC preprocessor definition isn't provided for the CEGUIOpenGLRenderer project (When explicitly adding this definition, everything is compiling/linking fine). Is this a bug or have I forgot to check some other cmake configuration option?

Thanks

[Ident]

OS, compiler, CEGUI version, error messages, ... ?

[Trigve]

Sorry, I totally forgot to mention it,
Window 7, Visual studio 2013, 32 bit build, CEGUI 0.8.4

Code: Select all

2>GL3FBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____glewBindFramebuffer
2>GL3FBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____glewCheckFramebufferStatus
2>GL3FBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____glewDeleteFramebuffers
2>GL3FBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____glewFramebufferTexture2D
2>GL3FBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____glewGenFramebuffers
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewBindBuffer
2>StateChangeWrapper.obj : error LNK2001: unresolved external symbol __imp____glewBindBuffer
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewBufferData
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewBufferSubData
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewDeleteBuffers
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewGenBuffers
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewEnableVertexAttribArray
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewUniformMatrix4fv
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewVertexAttribPointer
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewBindVertexArray
2>StateChangeWrapper.obj : error LNK2001: unresolved external symbol __imp____glewBindVertexArray
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewDeleteVertexArrays
2>GL3GeometryBuffer.obj : error LNK2001: unresolved external symbol __imp____glewGenVertexArrays
2>GL3Renderer.obj : error LNK2019: unresolved external symbol __imp__glewInit referenced in function "private: void __thiscall CEGUI::OpenGL3Renderer::initialiseGLExtensions(void)" (?initialiseGLExtensions@OpenGL3Renderer@CEGUI@@AAEXXZ)
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp__glewInit
2>GL3Renderer.obj : error LNK2019: unresolved external symbol __imp__glewGetErrorString referenced in function "private: void __thiscall CEGUI::OpenGL3Renderer::initialiseGLExtensions(void)" (?initialiseGLExtensions@OpenGL3Renderer@CEGUI@@AAEXXZ)
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp__glewGetErrorString
2>GL3Renderer.obj : error LNK2001: unresolved external symbol __imp____glewActiveTexture
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____glewActiveTexture
2>GL3Renderer.obj : error LNK2001: unresolved external symbol __imp____glewBlendFuncSeparate
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____glewBlendFuncSeparate
2>StateChangeWrapper.obj : error LNK2001: unresolved external symbol __imp____glewBlendFuncSeparate
2>GL3Renderer.obj : error LNK2001: unresolved external symbol __imp____glewUniform1i
2>GL3Renderer.obj : error LNK2001: unresolved external symbol __imp____glewGetStringi
2>GL3Renderer.obj : error LNK2001: unresolved external symbol __imp__glewExperimental
2>GLFBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____glewBindFramebufferEXT
2>GLFBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____glewDeleteFramebuffersEXT
2>GLFBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____glewFramebufferTexture2DEXT
2>GLFBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____glewGenFramebuffersEXT
2>GLFBOTextureTarget.obj : error LNK2001: unresolved external symbol __imp____GLEW_EXT_framebuffer_object
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____GLEW_EXT_framebuffer_object
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____glewClientActiveTexture
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____glewActiveTextureARB
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____glewClientActiveTextureARB
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____glewBlendFuncSeparateEXT
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____GLEW_VERSION_1_3
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____GLEW_VERSION_1_4
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____GLEW_ARB_multitexture
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____GLEW_EXT_blend_func_separate
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____GLEW_EXT_texture_compression_s3tc
2>GLRenderer.obj : error LNK2001: unresolved external symbol __imp____WGLEW_ARB_pbuffer
2>WGLPBTextureTarget.obj : error LNK2001: unresolved external symbol __imp____WGLEW_ARB_pbuffer
2>RendererBase.obj : error LNK2001: unresolved external symbol __imp____GLEW_ARB_texture_non_power_of_two
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewAttachShader
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewCompileShader
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewCreateProgram
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewCreateShader
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewDeleteProgram
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewDeleteShader
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewGetAttribLocation
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewGetProgramInfoLog
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewGetProgramiv
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewGetShaderInfoLog
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewGetShaderiv
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewGetUniformLocation
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewLinkProgram
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewShaderSource
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewUseProgram
2>Shader.obj : error LNK2001: unresolved external symbol __imp____glewBindFragDataLocation
2>Texture.obj : error LNK2001: unresolved external symbol __imp____glewCompressedTexImage2D
2>Texture.obj : error LNK2001: unresolved external symbol __imp____glewCompressedTexSubImage2D
2>Texture.obj : error LNK2001: unresolved external symbol __imp____glewGetCompressedTexImage
2>WGLPBTextureTarget.obj : error LNK2001: unresolved external symbol __imp____wglewCreatePbufferARB
2>WGLPBTextureTarget.obj : error LNK2001: unresolved external symbol __imp____wglewDestroyPbufferARB
2>WGLPBTextureTarget.obj : error LNK2001: unresolved external symbol __imp____wglewGetPbufferDCARB
2>WGLPBTextureTarget.obj : error LNK2001: unresolved external symbol __imp____wglewQueryPbufferARB
2>WGLPBTextureTarget.obj : error LNK2001: unresolved external symbol __imp____wglewReleasePbufferDCARB
2>WGLPBTextureTarget.obj : error LNK2001: unresolved external symbol __imp____wglewChoosePixelFormatARB
2>D:\work\Other\OpenGL\cegui-0.8.4\build\bin\CEGUIOpenGLRenderer-0_d.dll : fatal error LNK1120: 64 unresolved externals

[Ident]

I will quote from our bitbucket readme (https://bitbucket.org/cegui/cegui/overview) :

On Windows we heavily recommend to never use static linking with CEGUI and past experience has proven us right. A short summary of static vs dynamic linking can be found here: http://stackoverflow.com/questions/1993 ... ic-linking

Please first explain why you chose static linking.

[Trigve]

I'm not static linking CEGUI, I use CEGUI as DLL but with statically linked dependencies. As CEGUI dependencies are used only by the CEGUI I prefer static linking over dynamic.
So back to the topic, I think that CEGUI_BUILD_SHARED_LIBS_WITH_STATIC_DEPENDENCIES cmake option should also set the C++ preprocessor define for CEGUI generated projects.

[Ident]

The errors you get mean that the libraries aren't added to the linker settings. You could either add the manually (Solution->Properties->Linker->Input) to the specific projects that require them, or you can fix the CMake files so they will add them correctly out-of-the-box. If you manage to fix the CMake files please offer us a patch / pull request.

Maybe someone else can help you with what to edit in the CMake files or give you a solution directly, I am not up-to-date on these files.

EDIT: Redacted earlier (wrong) statements about static linking

[Trigve]

Thanks for the reply,
the dependency libraries are added to the project correctly. But if you link statically the imported symbol is named different when linking dynamically (because of dllimport() stuff defined in those dependency libs when linking dynamically). Long story shot, yes cmake need to be update accordingly. Only some preprocessor defines need to be added (Mainly GLEW_STATIC for glew) for CEGUI_BUILD_SHARED_LIBS_WITH_STATIC_DEPENDENCIES option.
I have very little experience with cmake. If someone could help, I could provide patch/pull request.

[Pyrce]

Glad I ran into this post -- I was getting 64 bit builds to work for PyCEGUI on Windows (yea it's been a task) and I was stuck on fixing this linkage issue for the OpenGLRenderer library. I had also toggled CEGUI_BUILD_SHARED_LIBS_WITH_STATIC_DEPENDENCIES and didn't realize it had shot me in the foot. I've got the cmake file fixed and I'll push a pull request up once I get a chance. I'll probably try turning if off after I get the build working regardless, since the downsides of shared libraries is heavily mitigated with the dependency builds being tightly controlable.

[Ident]

Glad I ran into this post -- I was getting 64 bit builds to work for PyCEGUI on Windows (yea it's been a task) and I was stuck on fixing this linkage issue for the OpenGLRenderer library. I had also toggled CEGUI_BUILD_SHARED_LIBS_WITH_STATIC_DEPENDENCIES and didn't realize it had shot me in the foot. I've got the cmake file fixed and I'll push a pull request up once I get a chance. I'll probably try turning if off after I get the build working regardless, since the downsides of shared libraries is heavily mitigated with the dependency builds being tightly controlable.

Wow that would be awesome! I am sure a lot of people would be very happy about that CMake fix.

Btw I must step back from my earlier statement indicating that static linking was always bad. I think it really depends on your application and environment. However, a problem can be if your application uses dependencies that are already used in CEGUI. If you statically link them in CEGUI but do not link CEGUI statically to your program then you might have them twice, for example, and maybe even different versions. The main reason we recommend against it in CEGUI is not because the idea itself is wrong but because a lot of people ran into technical issues. So if you know what you are doing, static linking is totally fine. I am also not sure if pycegui static linking works with CEED. Plugins are always dynamic. I am pretty sure CEED loads pyCEGUI dlls as a plugin. Just in case you building Pycegui for CEED.

[Pyrce]

This PR https://bitbucket.org/cegui/cegui/pull-request/161/fixed-static-build-dependency-build-for/diff got the static dependencies fixed enough for PyCEGUI to be run-able. It was a very small change once I narrowed down the problems. There's a few more static dependencies I didn't address in that PR which would need fixing if you wanted to use further libraries/alternatives. It'd be relatively easy for me to fix those as well, I just didn't need it to be able to build everything I'm using. Mostly it just appears the cmake files are missing `cegui_find_libraries` mappings or little compiler flags here and there. Note that you can build the dependencies statically and the CEGUI libraries dynamically still (which is what I was doing).

Btw, the manner in which PyCEGUI was configured it assumes that dependencies are statically linked into the dynamic CEGUI libraries. It didn't have the CEGUI dependencies mapped into the setup.py and python needed extra help to map those dependencies of the linked libraries if they were both dynamic. Only having one layer of dynamic libs is probably a better solution for python anyway. I recently got PyCEGUI with v0.8.4 working inside Panda3d v1.9.0 on 64 bit Windows. I was planning on making a PR back for updating the setup.py file which really needed some love to be (more) reusable. I'm not 100% sure I'll get to before I go on vacation, but late in the month for sure if not. That PR would probably also have some step-by-step documentation improvements for building and install PyCEGUI. Maybe this would be a couple of PRs.

[Ident]

Sounds good. Feel free to make as many PRs as you want. I will merge the Pr that you linked now and I will open a ticket for the raising of the warning message, as discussed in the comments of the PR.