Included new GLEW links agains the older GLEW from SFML :(

[Osbios]

Im trying to use SFML together with GLEW...

I was thinking I linked to the new version of GLEW. And it worked for some time. But I was wrong.

I include the glew.h and he links to the already existing entrys from the older GLEW of the sfml libs.

Only new entrys that are not present in the older GLEW are linked to my new glew.lib.
But there are not initialised because the init function (glewInit) that I call is also linked to the old GLEW.

One easy way would be to just swap the GLEW files from SFML agains the new ones and recompile. (I guess!?)

But isnt there a better way I could use my own glew? I found some threads in the forum about glew and it sounded like it was possible. So what am I doing wrong?

[christoph]

As long as GLEW doesn't do symbol veersioning both in the Version in SFML and in your Version you'll need to make sure to only have one version linked in at any point in time

[panithadrum]

I include the glew source into my project, and I think it works fine!

[Osbios]

OK my fault. It actualy worked. :/

I was using FBOs on a old card that did not have OpenGL 3.0. But FBOs are an extension until 3.0 and GLEW keeps the extension and the core functions seperat (e.g. glGenFramebuffersEXT and glGenFramebuffers)

And because I couldnt find glGenFramebuffers in the GLEW source of SFML I was thinking it hat to do with it.

Just linking to my GLEW version bevor SFML does work just fine.

[qweweng]

Hi, noob's passing by. I'm also having problems using the newer glew library with SFML that I do not know how to solve.

At first, I tried to link the newer glew library file to my project, but it gives multiple definition error for the glewInit() function as shown below:

G:\MinGW\lib\glew32.lib(d001590.o): multiple definition of `glewInit'
G:\Library\SFML-1.5\lib\libsfml-graphics-s.a(glew.o):glew.c:(.text+0xc560): first defined here

Then I remove the new glew library from the linker option to use the old glew library from SFML (should be the one in libsfml-graphics-s.a), but surprisingly the following linker errors pop out:

obj\Release\Application.o:Application.cpp:(.text+0x3fe): undefined reference to `_imp__glewInit'
obj\Release\Box.o:Box.cpp:(.text+0x2a8): undefined reference to `_imp____glewDrawRangeElements'
obj\Release\Box.o:Box.cpp:(.text+0x2f3): undefined reference to `_imp____glewDrawRangeElements'

I'm sure that my graphics card supports glDrawRangeElements function. I have read some threads in this forum about glew before posting and it seems possible to use newer glew with SFML, but I don't quite understand the solutions posted and I somehow couldn't get it right. Anyone knows what I have missed out?

I'm using SFML 1.5 btw. Thanks in advance for any help.

[Osbios]

G:\Library\SFML-1.5\lib\libsfml-graphics-s.a(glew.o):glew.c:(.text+0xc560): first defined here

This means you first linked to sfml before you linked to glew. But you have to link and include glew first!

What build system are you using?

[qweweng]

Hi, Osbios. Thanks for your quick reply.

I am using MinGW compiler and Code::Blocks IDE.

I have changed the linking order of libsfml-graphics-s.a and my newer glew, but the multiple redefinition error for glewInit() function still popped out. This time it stated that the glewInit() is first defined in glew32.lib instead. I am showing the full command line of my compilation if that helps. The linker error message is hightlighted in blue.

mingw32-g++.exe -LH:\MinGW\lib -LH:\Library\SFML\SFML-1.5\lib -LH:\Library\SFML\SFML-1.5\extlibs  -o bin\Release\MasterBase.exe obj\Release\Application.o obj\Release\Axes.o obj\Release\Box.o obj\Release\BruteForceTerrain.o obj\Release\FpsCamera.o obj\Release\FreeCamera.o obj\Release\Grid.o obj\Release\PolygonModel.o obj\Release\Terrain.o obj\Release\main.o   -s  H:\MinGW\lib\DevIL.lib H:\MinGW\lib\glew32.lib H:\Library\SFML\SFML-1.5\lib\libsfml-main.a H:\Library\SFML\SFML-1.5\lib\libsfml-graphics-s.a H:\Library\SFML\SFML-1.5\lib\libsfml-window-s.a H:\Library\SFML\SFML-1.5\lib\libsfml-system-s.a -lglu32 -lopengl32
H:\Library\SFML\SFML-1.5\lib\libsfml-graphics-s.a(glew.o):glew.c:(.text+0xc560): multiple definition of `glewInit'
H:\MinGW\lib\glew32.lib(d001590.o).text+0x0): first defined here

[Osbios]

I guess you try to link to the shared (DLL) version of glew?
Try the static version. Works fine for me.

[qweweng]

Thanks again, Osbios. Based on your suggestion, I tried several configurations and found the following surprising results:

(a) Static GLEW (glew32s.lib) and Static SFML libraries
     Result: ERROR - undefined reference to glewInit

(b) Dynamic GLEW (glew32.lib) and Static SFML libraries
     Result: ERROR - multiple definition error for glewInit, first defined in glew32.lib (glew32.lib comes first in the linker option)

(c) Static GLEW (glew32s.lib) and Dynamic SFML libraries
     Result: ERROR - undefined reference to glewInit

(d) Dynamic GLEW (glew32.lib) and Dynamic SFML libraries
     Result: WORKS!! BUT upon exit, the program crashes.

In terms of using GLEW with SFML, configuration (d) works fine for me so far. The reason why the program crashes seems to be because of mixing SFML drawing (such as Text) with OpenGL. I found this out when I compile the OpenGL sample that comes together with SFML 1.5. I don't know whether this happens to others or this problem has been solved in the newer versions. Any idea why?

[Laurent]

To use GLEW static, you need to define a preprocessor macro, something like GLEW_STATIC. This should solve your linker error in (a) and (c).

[panithadrum]

In terms of using GLEW with SFML, configuration (d) works fine for me so far. The reason why the program crashes seems to be because of mixing SFML drawing (such as Text) with OpenGL. I found this out when I compile the OpenGL sample that comes together with SFML 1.5. I don't know whether this happens to others or this problem has been solved in the newer versions. Any idea why?

Maybe because the known ATI bug.

[qweweng]

To Laurent:

Thanks a million for pointing out the GLEW macro. I completely missed that out. Now, configuration (a) and (c) works, but the result of (c) is the same as (d) in which the program crashes upon exit.

To panithadrum:

ATI bug? Do you mind sharing the detail of the bug (maybe a link to the bug information)? It sounds important.

[Laurent]

ATI bug? Do you mind sharing the detail of the bug (maybe a link to the bug information)? It sounds important.

Search "ati" and "crash" on this forum, you'll find hundreds of posts describing the issue.