It’s possible this is a little off-topic, but one of the errors below is SDL-related… Anyway, I’ve managed to get SDL 1.3 up and running today in Visual Studio, and gotten the demo programs running too. I’ve also gotten a test program of my own compiling, but not linking yet. The linker errors are below. Most are OpenGL errors (hence why it’s possibly off-topic for this list). I’m wondering, does this mean I need to install a newer version of OpenGL? As mentioned, the SDL gltest demo runs just fine. So it’s some of the other more obscure GL functions that aren’t linking, like glBufferData, glGenBuffers, glBindBuffer, etc. I have no idea why. My project is set to link against:
SDLmain.lib
sdl.lib
opengl32.lib
glu32.lib
The SDL linker error is for:
SDL_SelectMouse
Any thoughts welcome.
-Vern
1>------ Build started: Project: testgl, Configuration: Release Win32 ------
1>Simple.obj : error LNK2005: _SDL_main already defined in example.obj
1>BlitKernelGL.obj : error LNK2019: unresolved external symbol _glBindBuffer referenced in function _BKBlitGLSurfaceUsingVBO
1>Tiling.obj : error LNK2001: unresolved external symbol _glBindBuffer
1>BlitKernelGL.obj : error LNK2019: unresolved external symbol _glDeleteBuffers referenced in function _BKFreeGLSurface
1>Tiling.obj : error LNK2001: unresolved external symbol _glDeleteBuffers
1>BlitKernelSDL.obj : error LNK2019: unresolved external symbol _IMG_Load_RW referenced in function _BKLoadSurface
1>example.obj : error LNK2019: unresolved external symbol _SDL_SelectMouse referenced in function _SDL_main
1>Tiling.obj : error LNK2019: unresolved external symbol _glBufferSubData referenced in function _SWDrawTile
1>Tiling.obj : error LNK2019: unresolved external symbol _glBufferData referenced in function _SWComputeVBOForTileLayer
1>Tiling.obj : error LNK2019: unresolved external symbol _glGenBuffers referenced in function _SWComputeVBOForTileLayer
1>Win32\Release\testgl.exe : fatal error LNK1120: 7 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Are you trying to use the new OpenGL api (>= OpenGL 3.x)? If so, you may
need to use glew or gl3w in some systems (I can’t recall if this is
necessary in Mac - can someone confirm?). For the SDL linker issues, it may
be an issue with a mercurial revision, and it’s probably OS specific -
maybe try updating?
Anyway,I recommend using gl3w - it’s a python program that grabs the
appropriate opengl header, as well as a *.c source file that you can add to
your source file list, and it should build on any platform. I can help you
set that up if you’re not sure, otherwise here is the git repo:
I hope that helps,
-AlexOn Mon, Oct 31, 2011 at 8:19 PM, VernJensen wrote:
**
It’s possible this is a little off-topic, but one of the errors below is
SDL-related… Anyway, I’ve managed to get SDL 1.3 up and running today in
Visual Studio, and gotten the demo programs running too. I’ve also gotten a
test program of my own compiling, but not linking yet. The linker errors
are below. Most are OpenGL errors (hence why it’s possibly off-topic for
this list). I’m wondering, does this mean I need to install a newer version
of OpenGL? As mentioned, the SDL gltest demo runs just fine. So it’s some
of the other more obscure GL functions that aren’t linking, like
glBufferData, glGenBuffers, glBindBuffer, etc. I have no idea why. My
project is set to link against:
SDLmain.lib
sdl.lib
opengl32.lib
glu32.lib
The SDL linker error is for:
SDL_SelectMouse
Any thoughts welcome.
-Vern
1>------ Build started: Project: testgl, Configuration: Release Win32
1>Simple.obj : error LNK2005: _SDL_main already defined in example.obj
1>BlitKernelGL.obj : error LNK2019: unresolved external symbol
_glBindBuffer referenced in function _BKBlitGLSurfaceUsingVBO
1>Tiling.obj : error LNK2001: unresolved external symbol _glBindBuffer
1>BlitKernelGL.obj : error LNK2019: unresolved external symbol
_glDeleteBuffers referenced in function _BKFreeGLSurface
1>Tiling.obj : error LNK2001: unresolved external symbol _glDeleteBuffers
1>BlitKernelSDL.obj : error LNK2019: unresolved external symbol
_IMG_Load_RW referenced in function _BKLoadSurface
1>example.obj : error LNK2019: unresolved external symbol _SDL_SelectMouse
referenced in function _SDL_main
1>Tiling.obj : error LNK2019: unresolved external symbol _glBufferSubData
referenced in function _SWDrawTile
1>Tiling.obj : error LNK2019: unresolved external symbol _glBufferData
referenced in function _SWComputeVBOForTileLayer
1>Tiling.obj : error LNK2019: unresolved external symbol _glGenBuffers
referenced in function _SWComputeVBOForTileLayer
1>Win32\Release\testgl.exe : fatal error LNK1120: 7 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
OpenGL.dll on Windows does not export any functions beyond OpenGL 1.1, because the function implementations can be different for different GL contexts, depending on how they’re set up.? You need to create function pointers with the right signatures at your end and use SDL_GL_GetProcAddress to retrieve the right addresses for the function pointers for use with your SDL window.________________________________
From: vern@actionsoft.com (VernJensen)
To: sdl at lists.libsdl.org
Sent: Monday, October 31, 2011 5:19 PM
Subject: [SDL] OpenGL linker errors?
It’s possible this is a little off-topic, but one of the errors below is SDL-related… Anyway, I’ve managed to get SDL 1.3 up and running today in Visual Studio, and gotten the demo programs running too. I’ve also gotten a test program of my own compiling, but not linking yet. The linker errors are below. Most are OpenGL errors (hence why it’s possibly off-topic for this list). I’m wondering, does this mean I need to install a newer version of OpenGL? As mentioned, the SDL gltest demo runs just fine. So it’s some of the other more obscure GL functions that aren’t linking, like glBufferData, glGenBuffers, glBindBuffer, etc. I have no idea why. My project is set to link against:
SDLmain.lib
sdl.lib
opengl32.lib
glu32.lib
The SDL linker error is for:
SDL_SelectMouse
Any thoughts welcome.
-Vern
1>------ Build started: Project: testgl, Configuration: Release Win32 ------
1>Simple.obj : error LNK2005: _SDL_main already defined in example.obj
1>BlitKernelGL.obj : error LNK2019: unresolved external symbol _glBindBuffer referenced in function _BKBlitGLSurfaceUsingVBO
1>Tiling.obj : error LNK2001: unresolved external symbol _glBindBuffer
1>BlitKernelGL.obj : error LNK2019: unresolved external symbol _glDeleteBuffers referenced in function _BKFreeGLSurface
1>Tiling.obj : error LNK2001: unresolved external symbol _glDeleteBuffers
1>BlitKernelSDL.obj : error LNK2019: unresolved external symbol _IMG_Load_RW referenced in function _BKLoadSurface
1>example.obj : error LNK2019: unresolved external symbol _SDL_SelectMouse referenced in function _SDL_main
1>Tiling.obj : error LNK2019: unresolved external symbol _glBufferSubData referenced in function _SWDrawTile
1>Tiling.obj : error LNK2019: unresolved external symbol _glBufferData referenced in function _SWComputeVBOForTileLayer
1>Tiling.obj : error LNK2019: unresolved external symbol _glGenBuffers referenced in function _SWComputeVBOForTileLayer
1>Win32\Release\testgl.exe : fatal error LNK1120: 7 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Okay makes sense, thanks!!
Mason Wheeler wrote:
OpenGL.dll on Windows does not export any functions beyond OpenGL 1.1, because the function implementations can be different for different GL contexts, depending on how they’re set up. You need to create function pointers with the right signatures at your end and use SDL_GL_GetProcAddress to retrieve the right addresses for the function pointers for use with your SDL window.
Tried this (actually using SDL_GL_GetProcAddress), but while this works for most GL functions, it returns NULL for:
glGenBuffers
Is there something I need to do when linking to get this to return non-NULL?
-Vern
glGenBuffersARB? I’d think the first form would exist though…On Tue, Nov 1, 2011 at 4:33 PM, VernJensen wrote:
**
Mason Wheeler wrote:
OpenGL.dll on Windows does not export any functions beyond OpenGL 1.1,
because the function implementations can be different for different GL
contexts, depending on how they’re set up. You need to create function
pointers with the right signatures at your end and use
SDL_GL_GetProcAddress to retrieve the right addresses for the function
pointers for use with your SDL window.
Tried this (actually using SDL_GL_GetProcAddress), but while this works
for most GL functions, it returns NULL for:
glGenBuffers
Is there something I need to do when linking to get this to return
non-NULL?
-Vern
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
@VernJensen, like I said, using glew or gl3w is good. What it does is
loads all the opengl 3.x+ functions for you, so you just use them - no fuss
with SDL_GL_GetProcAddress 
-AlexOn Tue, Nov 1, 2011 at 5:35 PM, Patrick Baggett <baggett.patrick at gmail.com>wrote:
glGenBuffersARB? I’d think the first form would exist though…
On Tue, Nov 1, 2011 at 4:33 PM, VernJensen wrote:
**
Mason Wheeler wrote:
OpenGL.dll on Windows does not export any functions beyond OpenGL 1.1,
because the function implementations can be different for different GL
contexts, depending on how they’re set up. You need to create function
pointers with the right signatures at your end and use
SDL_GL_GetProcAddress to retrieve the right addresses for the function
pointers for use with your SDL window.
Tried this (actually using SDL_GL_GetProcAddress), but while this works
for most GL functions, it returns NULL for:
glGenBuffers
Is there something I need to do when linking to get this to return
non-NULL?
-Vern
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
MrOzBarry wrote:
@VernJensen, like I said, using glew or gl3w is good. What it does is loads all the opengl 3.x+ functions for you, so you just use them - no fuss with SDL_GL_GetProcAddress :)-Alex
…but if I already have the code to use SDL_GL_GetProcAddress, and it’s not a matter of that code not being present or not working, but rather some kind of linker error, I’m not sure why switching to gl3w would help?
I guess I’d prefer not to switch if there is a simple alternative fix here, since all code currently calls
gl->glFunction()
where the gl structure is loaded with the proc accresses of all GL functions I use. So to switch to gl3w would actually require a bit of rewriting, to remove all the gl-> stuff.
But my question is, isn’t this essentially a linker error, given that the proc address for a particular function is null? Or to rephrase: wouldn’t it be that I am somehow linking against an older OpenGL library – one that doesn’t have this function in it? I guess that’s what I’m trying to ask. How do I link against a more current OpenGL library on Windows with Visual Studio. (If my assumption that this is the problem is correct.)
This could be the linker, or it could be that you don’t have OpenGL >= 3.x
supported by your graphics card. Also, you need to be sure you are setting
the gl context version to be at least 3.1 for most of the gl*buffer
functions.
-AlexOn Wed, Nov 2, 2011 at 11:44 AM, VernJensen wrote:
**
MrOzBarry wrote:
@VernJensen, like I said, using glew or gl3w is good. What it does is
loads all the opengl 3.x+ functions for you, so you just use them - no fuss
with SDL_GL_GetProcAddress [image: Smile]-Alex
…but if I already have the code to use SDL_GL_GetProcAddress, and it’s
not a matter of that code not being present or not working, but rather some
kind of linker error, I’m not sure why switching to gl3w would help?
I guess I’d prefer not to switch if there is a simple alternative fix
here, since all code currently calls
gl->glFunction()
where the gl structure is loaded with the proc accresses of all GL
functions I use. So to switch to gl3w would actually require a bit of
rewriting, to remove all the gl-> stuff.
But my question is, isn’t this essentially a linker error, given that
the proc address for a particular function is null? Or to rephrase:
wouldn’t it be that I am somehow linking against an older OpenGL library –
one that doesn’t have this function in it? I guess that’s what I’m trying
to ask. How do I link against a more current OpenGL library on Windows with
Visual Studio. (If my assumption that this is the problem is correct.)
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
MrOzBarry wrote:
This could be the linker, or it could be that you don’t have OpenGL >= 3.x supported by your graphics card. Also, you need to be sure you are setting the gl context version to be at least 3.1 for most of the gl*buffer functions. -Alex
I’m happy to try that, but hope you don’t mind a simple question first… All of the functions I’m using that are giving me trouble are, according to the OpenGL online documentation, part of the 1.5 specification:
glGenBuffers
glBindBuffer
glBufferData
glBufferSubData
glDeleteBuffers
For instance, see the manal page for glGenBuffers at the bottom where it gives version info:
http://www.opengl.org/sdk/docs/man/xhtml/glGenBuffers.xml
“glGenBuffers is available only if the GL version is 1.5 or greater.”
According to a test program I just ran, the version of OpenGL driver on my system is 2.1.
Same for all the functions above. The documentation states they are available in 1.5. If they required 3.x instead, it’d certainly make sense why they aren’t linking. Are the manual pages incorrect, or I’m not understanding something correctly?
Also, I checked, and at start-up I’m calling:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 2);
so requesting OpenGL 3.2. Seems fine there.
Huh, I was told the buffer functions were started with opengl 3.x, but I
guess that was wrong. Now I’m just stumped, althought just as someone had
suggested, it might be an issue with ARB; check out
http://nehe.gamedev.net/tutorial/vertex_buffer_objects/22002/
Hopefully that helps you out a bit,
-AlexOn Wed, Nov 2, 2011 at 1:22 PM, VernJensen wrote:
**
Also, I checked, and at start-up I’m calling:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 2);
so requesting OpenGL 3.2. Seems fine there.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Do you have an existing, active SDL window with an OpenGL renderer before you make these GetAddress calls? Not having one can cause them to fail.________________________________
From: alex.barry@gmail.com (Alex Barry)
To: sdl at lists.libsdl.org
Sent: Wednesday, November 2, 2011 10:39 AM
Subject: Re: [SDL] OpenGL linker errors?
Huh, I was told the buffer functions were started with opengl 3.x, but I guess that was wrong. ?Now I’m just stumped, althought just as someone had suggested, it might be an issue with ARB; check out?http://nehe.gamedev.net/tutorial/vertex_buffer_objects/22002/
Hopefully that helps you out a bit,
-Alex
On Wed, Nov 2, 2011 at 1:22 PM, VernJensen wrote:
Also, I checked, and at start-up I’m calling:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 2);
so requesting OpenGL 3.2. Seems fine there.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Mason Wheeler wrote:
Do you have an existing, active SDL window with an OpenGL renderer before you make these GetAddress calls? Not having one can cause them to fail.
Previously, no, but I modified my code, and now, yes. But no change in program behavior.
As a side note though, I do successfully load about 20 other GL functions – which all load successfully – prior to loading these 5 that fail. If it were the issue you mention above, would some load and not others, or would all fail?