Sign in to follow this  

Linker errors Eugh!

This topic is 796 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Can anyone tell me why I cannot get -lglew32 to link at all.

 

Compiler is codeblocks

 

I've made sure it's the 32bit version

 

I've even tried copying the .dll into the folder to bypass and when I put -lglew32 in the linker section it just dies. It's very frustrating:

 

ld.exe||cannot find -lglew32|

 

Your help will be much appreciated

Share this post


Link to post
Share on other sites

Your IDE is codeblocks, what compiler\Linker do you have? (I bet gcc?) 

 

I've had issues with ld.exe before, you need to specifiy the finding path with -L. 

 

Hope it helps! 

 

Editr:

+After a lot of sessions fixing my own linker I found few solutions:

My linker uses the convention <dllname>.dll.a

So try to generate or get files with such names. 

+ Maybe you are trying to use libraries built for windows via VS, something that did fix it,

Recompiling the libraries on your own, especially glew or if you use glfw3. 

Edited by WoopsASword

Share this post


Link to post
Share on other sites

I've even tried copying the .dll into the folder to bypass and when I put -lglew32 in the linker section it just dies. It's very frustrating:


This raises an immediate alarm. The DLL is completely irrelevant at link time, what you need to care about is the corresponding .lib file (or .a file, depending on which naming convention was followed during build).

Share this post


Link to post
Share on other sites

 

I've even tried copying the .dll into the folder to bypass and when I put -lglew32 in the linker section it just dies. It's very frustrating:


This raises an immediate alarm. The DLL is completely irrelevant at link time, what you need to care about is the corresponding .lib file (or .a file, depending on which naming convention was followed during build).

 

 

Okay for this bit I have a folder in my project directory called 'lib' -minus quotes- and within it the two following files:

glew32.lib

glew32s.lib

 

in my main.cpp i have the following include:

#include <GL/glew.h>

 

If I link these using and of the following compiler flags (in Project build options->Linker settings->Other linker options) I get: ld.exe||cannot find -lglew|

-lglew32

-lglew

-lGLEW

Share this post


Link to post
Share on other sites

AH HA found out why!

 

This dude -link below- explains in his video that the GLEW files are precompiled for visual studio and not minGW so that's why they won't work:

https://www.youtube.com/watch?v=UwpZOwT9nVc

 

He gives links to pre-compiled files -link below- for minGW so you can get it running, how frustrating!

http://www.grhmedia.com/glew.html

Share this post


Link to post
Share on other sites

Do I need GLEW or can I just use SDL2 and run all input and sound through that? What's the difference between them as I'm not really sure why I'm wasting my time and sanity trying to get GLEW working.

 

Does anyone have any experience with them?

Share this post


Link to post
Share on other sites

Technically you can just skip glew and SDL2 altogether and just use the win32 api on windows and X11 on linux and mac. For a beginner tutorial not recommended. You will have to manage getting SDL2 dll's on every users computer to run your exe though.

I'm not sure why glew is needed. I don't see it used in the tutorial source code.

Share this post


Link to post
Share on other sites

This dude -link below- explains in his video that the GLEW files are precompiled for visual studio and not minGW so that's why they won't work:

While static libraries compiled for one compiler are usually not compatible with libraries compiled by another compiler that is not always the case (for example gcc and clang are meant to largely inter-operate). At the same time even within the same compiler you can have incompatibilities.
The most common example is MSVC and the used runtime. Usually you will need two version of a library (one linking to the Debug and one linking to the Release runtime). Mixing them will (depending on the circumstances and version of MSVC) not work at all or cause highly subtle but ultimately fatal bugs. Apart from that MSVC allows you to chose between two different runtimes (each with a Debug and Release variant) and there are even compile flags/definitions which can make compiled incompatible.
Note that for a pure C library (like GLEW is) this would normally not matter but most prepared MSVC-packages I have seen are set up in a way that they will still cause subtle issues by pulling in the wrong standard library if mishandled.
Linking dynamically largely alleviates the problem (provided the library has properly designed pure C interface) but having to distribute possibly another runtime library just because the library was compiled in the wrong way is extremely annoying.
 

He gives links to pre-compiled files -link below- for minGW so you can get it running, how frustrating!

I would strongly recommend you get into the habit of building libraries you use yourself. First, it is extremely good practice, second at some point you be in a position where you will need to do that anyway: You might be using MSVC 2013 but the library you need to use is only available precompiled for MSVC 2008 or any other scenario. You might also need to use compile settings which are uncommon and break the ABI.
I have personally seen how wrong things can go if you rely on prebuilt files, even straight from the creators. For example I once ran into a severe trouble with pthread because of this. Despite the fact it's a pure C library the prebuilts from the official site link dynamically to the C++ runtime which is unfortunately not mentioned anywhere, nor the version. Long story short, the whole program failed in a cryptic way on some customer machines until I compiled it myself under known parameters.
 

One more issue is that if you use the pre-compiled files then they might be for a different version of windows and still cause errors. 
 
e.g.
glewGetErrorString@4 could not be located

That is highly unlikely. That probably means someone compiled the library wrong.
 

Do I need GLEW or can I just use SDL2 and run all input and sound through that? What's the difference between them as I'm not really sure why I'm wasting my time and sanity trying to get GLEW working.

You will need something like GLEW on Windows. Windows does not give you anything more than OpenGL 1.1 (which is not really enough to do anything fun and interesting) and everything else has to be queried over the extension mechanism. That is a lot of boring work. I would also advise against trying to muck around with function pointers (and all the interesting problems that can happen when you cast them to the wrong type) if dealing with library linkage already gives you so much trouble.

Share this post


Link to post
Share on other sites

 if dealing with library linkage already gives you so much trouble.

 

 

I think this is a total lack of experience and blindly throwing myself into something I no one to talk to about or any where I can learn this stuff (or at least that's my perception at this time).

Share this post


Link to post
Share on other sites

This topic is 796 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this