Link error with Qt 4.8.2 and SOIL

[fiodis]

I'm using the Simple OpenGL Image Library to load a TGA file and get a GLuint texture ID for use with OpenGL 3.1, rather than through Qt's QImage and QGL wrappers. I added LIBS += C:/Qt/qtcreator-2.5.2/lib/libSOIL.lib and INCLUDEPATH += C:/Qt/qtcreator-2.5.2/include/ to my project's .PRO file. I also put SOIL.h in C:/Qt/qtcreator-2.5.2/include/, and libSOIL.lib in C:/Qt/qtcreator-2.5.2/lib. Lastly, I added #include <SOIL.h> to all headers that required it.

The project compiles fine if I don't call any SOIL functions. The moment I try to call a SOIL function, though, I get a link error talking about an unresolved external symbol in libSOIL.lib. Has anyone gotten SOIL to link properly with Qt Creator 2.5.2? What could be causing the problem I'm seeing? Are there any other methods of loading a TGA file in Qt, aside from writing my own loader from scratch?

Is there a way of using Qt to load a tga file and get back a normal GLuint texture ID?

[ChrisW67]

Qt Creator 2.5.2 is not a compiler or linker. It makes no sense to ask "Has anyone gotten SOIL to link properly with Qt Creator 2.5.2?"

Remove the files you copied into the Qt directories.

In your PRO file:

SOILPATH = "c:/Simple OpenGL Image Library"
INCLUDEPATH += "$${SOILPATH}/src"
LIBS += -L"$$(SOILPATH)/lib" -lSOIL

SOILPATH = "c:/Simple OpenGL Image Library"
INCLUDEPATH += "$${SOILPATH}/src"
LIBS += -L"$$(SOILPATH)/lib" -lSOIL

To copy to clipboard, switch view to plain text mode 

Adjust SOILPATH to point at where you extracted/built the SOIL library. If it still does not link post the actual error messages and tell us what compiler/toolchain you are using.

A TGA (Targa) file format plugin is part of Qt5. You may be able to easily back port it or simply use Qt5. This will not give you anything direct OpenGL related though.

[fiodis]

Making those adjustments fixed the issue, thanks! Quick question: what do the flags in the LIBS += line mean?

[ChrisW67]

qmake Project Files : Declaring Other Libraries

The paths to the libraries themselves can be given, or the familiar Unix-style notation for specifying libraries and paths can be used if preferred.

These are the "familiar Unix-style notation"
-Lpath: adds a path to the list of paths the linker will search looking for libraries it needs to resolve missing symbols
-lname: (lower case L) names a library to use when linking the program. On UNIX-like systems (and MingW) the library file is actually named libname.a and on Windows with MSVC the library file is name.lib