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)

Hybrid View

  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,194
    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,194
    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!

Posting Permissions

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