linking nvidia pbuffer's


The wgl Commands are not recognized in the linking phase of my building…, why ?
I have been looking at the settings of the pbuffer’s examples that came with opengl sdk, and i have all the libraries they have…, as this is a linking problem i must be missing something here…, what ?

pbuffer.obj : error LNK2001: unresolved external symbol “int (stdcall* wglDestroyPbufferARB)(struct HPBUFFERARB )" (?wglDestroyPbufferARB@@3P6GHPAUHPBUFFERARB__@@@ZA)
pbuffer.obj : error LNK2001: unresolved external symbol "int (__stdcall
wglReleasePbufferDCARB)(struct HPBUFFERARB__ *,struct HDC__ )" (?wglReleasePbufferDCARB@@3P6GHPAUHPBUFFERARB__@@PAUHDC__@@@ZA)
pbuffer.obj : error LNK2001: unresolved external symbol "int (__stdcall
wglQueryPbufferARB)(struct HPBUFFERARB__ *,int,int )" (?wglQueryPbufferARB@@3P6GHPAUHPBUFFERARB__@@HPAH@ZA)
pbuffer.obj : error LNK2001: unresolved external symbol "struct HDC__ * (__stdcall
wglGetPbufferDCARB)(struct HPBUFFERARB__ )" (?wglGetPbufferDCARB@@3P6GPAUHDC__@@PAUHPBUFFERARB__@@@ZA)
pbuffer.obj : error LNK2001: unresolved external symbol "struct HPBUFFERARB__ * (__stdcall
wglCreatePbufferARB)(struct HDC__ *,int,int,int,int const )" (?wglCreatePbufferARB@@3P6GPAUHPBUFFERARB__@@PAUHDC__@@HHHPBH@ZA)
pbuffer.obj : error LNK2001: unresolved external symbol "int (__stdcall
wglChoosePixelFormatARB)(struct HDC__ *,int const *,float const *,unsigned int,int *,unsigned int *)” (?wglChoosePixelFormatARB@@3P6GHPAUHDC__@@PBHPBMIPAHPAI@ZA)
Debug/q3.exe : fatal error LNK1120: 6 unresolved externals
Error executing link.exe.

You don’t link to extensions – you dynamically link at runtime using wglGetProcAddress. WGL extensions are no different in this way.

  • Matt


Please download the NVIDIA OpenGL SDK for examples of how to use pbuffers.

Thanks -

I ran into a similar problem when I was trying to setup the functions for multitexturing.

My problem had to do with defining the functions in one header file and using them in a completely different cpp file. When it tried to link it couldn’t find a definition for the functions so it wouldn’t link (I think it was the same error your getting). The linker didn’t realise that they will eventually get linked at run time. For some reason I didn’t get this problem when I had all the code in one set of header and cpp files.

I fixed it by defining a fake body in one of my cpp files like this:
glActiveTextureArb(…); //no brackets I think

I think the linker used this as the definition and linked ok. Then at runtime they get redefined to the proper entry points.


I’m getting really desesperated with this…, why isn’t this working ?
damn…, i’m just doing the following:

In my main file i just included the pbuffer.cpp that cames with the opengl sdk.
I can compile just fine, but it’s not linking…, i tried several other ways, but unsucesseful
stecher, how do i do what you say in this case ? I will try anything to make this work.




I’m not familiar with the pbuffer.cpp file from the SDK, so hopefully my work around will work for you.

First of all I used the below instructions to setup my extensions:

Everything worked fine as long as I had all the declarations in one header file and all the definitions (including the code that dynamically links the wgl calls) in the one cpp file. If I made all the calls of the extension functions in that same cpp file everything linked ok.

The linking problem happened when I moved the declarations and definitions to one set of header and cpp files, but I included the header and used the extension calls in other cpp files. I don’t have any idea why this caused problems, but it did. My program wouldn’t link anymore, and I got unresolved external errors like yours.

The solution was simply to define the extension functions in the cpp file that had all my extension code. That way the linker would see a function definition and wouldn’t complain. At run time the functions would be re-linked to the proper wgl entry points. (at least that’s how I think it worked…I was pretty frustrated by this problem and kind of stumbled on to the solution)
Anyway the way I temporarily defined the extension functions was like this:

in the header file you might declare an extension function like this:

in the cpp file I had to define it like this:
PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT(GLenum pname, GLfloat param);

I think this makes the linker happy because it thinks the function is defined (just a guess, if someone knows better please let me know):

somewhere else in the cpp file the extention function is redefined at runtime to point at the proper entry point:

I’m pretty sure this was the syntax. If its wrong let me know and I can paste a code snippet up here later today.

Good luck with this problem it took me a long time - with a lot of trial and error - to get it linking.

BTW: I’m using Visual C++ 5.0. I don’t know if that makes any difference.

Oh! This is a glh_extensions.h issue. There must be exactly one cpp file in your build that does this:

#include <glh_extensions.h>

and all the rest (that use extensions) must do this:

#include <glh_extensions.h>

without the #define from above.

This causes the symbols to be declared extern (and functions as prototypes only)everywhere except the one CPP file, where they’re declared normally, and the functions are defined.

This is essentially piggybacking a C file onto one of the other C files in a build so that we don’t have to distribute glh_extensions.h as a h/cpp/lib. Just a header.

Sorry for the confusion.


That clears things up for me. I wish I knew this a few weeks ago

In case my workaround comes in usefull for anyone here is the exact syntax:

in the header:

in the cpp:
void (WINAPI* glActiveTextureARB)(unsigned int tmp);

This allowed me to include the header and use the above function in any file I needed.

Thanks guys…, got it working
interesting that #define stuff