Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 9 of 9

Thread: Linker problems to GLEW (can't be my graphic card, can it)

  1. #1
    Junior Member Newbie
    Join Date
    Dec 2012
    Posts
    6

    Linker problems to GLEW (can't be my graphic card, can it)

    First of all, hi! I'm a 2nd year in IT that's into game design, and recently came across a stump, because software rendering is taking too big a chunk of out my CPU to be viable, and so I'm trying to set up OpenGL, to learn a little of it, and have my graphics be drawn by the graphics card, freeing my CPU for the rest of the logistics!

    I'm programming c++, in Code::Blocks IDE, using SDL for the context framework, and as seen everywhere, trying to set up glew to ease OpenGL's use.

    And I'm having some issues with the linker setup, namely:

    obj\Release\main.o:main.cpp.text+0x49): undefined reference to `_imp__glewExperimental'

    obj\Release\main.o:main.cpp.text+0x66): undefined reference to `_imp____glewGenBuffers'

    I think I did it all right:

    -glew32.dll to sys64 (the folder where windows gets the .dll)

    -search libs to glew lib folder

    -search includes to glew include folder

    -add glew32.lib to linker

    It's detecting the lib well I believe, because without it I can't compile glewInit(); right.

    My includes are:

    #include <GL/glew.h>
    #include <SDL/SDL.h>

    I'm starting to suspect (based on a friend's advice) that it may be my graphic card... but it's "recent", HD 5470 mobility.
    I've been, exaggerations aside, an entire afternoon and evening yesterday trying to get this to work!

    Thank you!

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,125
    If it's a link error, it almost certainly doesn't have anything to do with your graphics card.

    Just websearch on your error message. These are two of the first posts that come up:

    * http://old.nabble.com/glewExperiment...td8217153.html
    * http://www.gamedev.net/topic/581656-glew-linker-errors/

  3. #3
    Junior Member Newbie
    Join Date
    Dec 2012
    Posts
    6
    Yeah, I've been to those and dozens others countless times already. I've posted twice to stackOverflow, and no one's being able to tell what's wrong, what the friend told me is that my graphic card could be old, and therefore doesn't support those instructions, or something like it. (I have no idea, I'm not experienced in this area... am completely new)

  4. #4
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    I kinda hate advertising my own stuff, but have you considered not using GLEW? The static vs. DLL issue is almost certainly what's catching you here. GLEW can be built as a static library or as a shared library. You can link to the .lib for the static or shared library. And you can compile your code against the static or shared library.

    The problem is that everyone must agree. If you want to use GLEW as a static library correctly, you must build it as a static library, link to the static library in your project, and build your project using the appropriate #define that tells it to use a static library. The same goes for dynamic. If you don't do this correctly, you'll get a linker error.

    There are other OpenGL loaders you can use, and many of them don't have this static vs. dynamic issue. GL3W provides core OpenGL (and only core OpenGL) as a static library. glLoadGen always links statically; it's not even a library in the strictest since of that term. You generate .h and .cpp files, and you simply include them into your project as though they were your own files. The OpenGL SDK's GL Load system provides all extensions and specialized headers, but it's slightly more complex to link to than simply including .h and .cpp files in your project.

    In short, if you're having trouble with GLEW, while it's good to learn how to work through those problems, there are alternatives you should consider.

  5. #5
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,125
    Quote Originally Posted by Alfonse Reinheart View Post
    The problem is that everyone must agree. If you want to use GLEW as a static library correctly, you must build it as a static library, link to the static library in your project, and build your project using the appropriate #define that tells it to use a static library. The same goes for dynamic. If you don't do this correctly, you'll get a linker error.
    Yeah, such are the joys of Windoze's __declspec(dllexport) / __declspec(dllimport) annoyance. Tremendous source of code clutter.

    In Linux, by default it just works -- no silly "am I going to link with a shared (dll) or static library" nonsense at compile time. You shouldn't have to know, and you don't!

    Though if you want to be paranoid and hide a bunch of globals that probably shouldn't have been global in the first place (hint!), then there is __attribute__ ((visibility))

    (And just to clarify "everyone" in your post, by this I assume you mean all the constituent code in your application -- not all code on the machine, which is what I first thought.)
    Last edited by Dark Photon; 01-02-2013 at 10:16 AM.

  6. #6
    Junior Member Newbie
    Join Date
    Dec 2012
    Posts
    6
    Wow thanks for the replies! Yeah, I considered using others: I tried gl3w, but it won't work: the .py script keeps blabbing about Error Syntax and won't lead to anything... and couldn't find any solution for that.
    As for glLoadGen, I'll try it now, thanks!

  7. #7
    Junior Member Newbie
    Join Date
    Dec 2012
    Posts
    6
    EDIT: I had no idea I needed a backwards python! Gl3w needs to have 2.7 or before that, others won't suffice! Hope I get this one working proper.

    And more issues...

    Function that's built by Gl3w script which has the errors:

    static void *get_proc(const char *proc) - line 19
    {
    void *res;

    res = wglGetProcAddress(proc); - line 23, first error
    if (!res)
    res = GetProcAddress(libgl, proc); - line 25, second error
    return res;
    }
    Build errors:

    ||=== LearnOPG, Debug ===| C:\CodeBlocks\LearnOPG\gl3w.c||In function 'void* get_proc(const char*)':|

    C:\CodeBlocks\LearnOPG\gl3w.c|23|error: invalid conversion from 'PROC {aka int (attribute((stdcall)) )()}' to 'void' [-fpermissive]|

    C:\CodeBlocks\LearnOPG\gl3w.c|25|error: invalid conversion from 'FARPROC {aka int (attribute((stdcall)) )()}' to 'void' [-fpermissive]|

    ||=== Build finished: 2 errors, 0 warnings (0 minutes, 0 seconds) ===|
    Last edited by GigaBass; 01-01-2013 at 04:40 PM.

  8. #8
    Junior Member Newbie
    Join Date
    Dec 2012
    Posts
    6
    Can you give me detailed instructions on what to do if possible, in order to set up gl3w?

    I'm getting undefined references to wglGetProdAddres@4. Googling it up, but detailed instructions on what I should do regarding the entire gl3w setup would be great if possible, the site is so short on help.

    Thanks.

  9. #9
    Junior Member Newbie
    Join Date
    Dec 2012
    Posts
    6
    I managed to get it working! Small "guide" on the steps to go about setting gl3w:

    First of all, download gl3w at https://github.com/shakesoda/gl3w

    Then, download Python 2.7.3:

    http://www.python.org/download/releases/2.7.3/

    (can't be the latest version, because the script's not made for it)

    Next, run the script. It'll generate glew.c in the source folder, and glew.h and glcorearb.h in the include/GL/ folder.

    Take the three of them, and either add them directly to your project, or (easier to do the includes), move them into your project's source files folder, and add the 3 into the project.

    In your main source AND in your "glew.c" source, you want to change the include to #include "gl3w.h" Consequently, you'll have to change gl3w.h's include to #include "glcorearb.h"

    This is because you changed their folder setups, the compiler will throw "can't find xxx" otherwise.

    And don't forget to link to "opengl32", simply add the library as such. In Code::Blocks, you select the root project, go into "build options", select the root project once again (above Debug and Release), go to Linker Settings, Add, and type just "opengl2" without the quotes.

    That's all!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •