LNK2001 unresolved external symbol for SHA3 class members - c++

I am need to calculate SHA3 in my program as well as use AES in my sockets and have decided to use crypto++ library.
I am new to Visual Studio environment with no prior experience on visual studios but have extensively worked on g++ (linux/mingw-w64). One of the third part library I am using recommends Visual Studios (causes linker error when used with g++).
I am getting an linker error.
Error :
LNK2001 unresolved external symbol "public: virtual void __cdecl CryptoPP::SHA3::Update(unsigned char const *,unsigned __int64)" (?Update#SHA3#CryptoPP##UEAAXPEBE_K#Z) ConsoleApplication2 C:\Users\Admin\source\repos\ConsoleApplication2\ConsoleApplication2\ConsoleApplication2.obj 1
LNK2019 unresolved external symbol "public: virtual void __cdecl CryptoPP::SHA3::Restart(void)" (?Restart#SHA3#CryptoPP##UEAAXXZ) referenced in function "public: __cdecl CryptoPP::SHA3::SHA3(unsigned int)" (??0SHA3#CryptoPP##QEAA#I#Z) ConsoleApplication2 C:\Users\Admin\source\repos\ConsoleApplication2\ConsoleApplication2\ConsoleApplication2.obj 1
Error LNK2001 unresolved external symbol "public: virtual void __cdecl CryptoPP::SHA3::TruncatedFinal(unsigned char *,unsigned __int64)" (?TruncatedFinal#SHA3#CryptoPP##UEAAXPEAE_K#Z) ConsoleApplication2 C:\Users\Admin\source\repos\ConsoleApplication2\ConsoleApplication2\ConsoleApplication2.obj 1
The same code works properly in g++(mingw-w64 - I am using dll created in mingw-w64)
OS : Windows 10 Pro 64 bit
Development Environment : Visual Studios 2017
Target : Debug x64
Source :
#include <sha3.h>
#include <filters.h>
#include <hex.h>
#include <string>
#include <iostream>
#include <vector>
#include <algorithm>
#include <iostream>
#include <base64.h>
int main()
{
CryptoPP::SHA3_512 hash;
std::cout << hash.AlgorithmName() << " Test." << std::endl;
std::string in = "The quick brown fox jumps over the lazy dog";
std::vector<CryptoPP::byte> out(hash.DigestSize());
hash.CalculateTruncatedDigest(&out[0], hash.DigestSize(), reinterpret_cast<CryptoPP::byte*>(&in[0]), in.size());
std::cout << in << std::endl;
std::cout.setf(std::ios::hex, std::ios::basefield);
for_each(out.begin(), out.end(), [](CryptoPP::byte i) {
printf("%x", i);
});
std::cout << "Original String : " << str << std::endl;
return 0;
}
Kindly advice me how to load (copy) all generated dll in some common folder just like the make install command (facility) in gcc.
Edit :
I have added cryptopp.lib in additional dependencies and added the folder containing both cryptopp.lib and cryptopp.dll in Additional Library Directory. I have added the directory in Path environment variable. I have selected Multi Threaded Debug Dll in Debug x64 configuration during dll generation in cryptolib project.

Paul Sanders is quite correct, the classes and functions you want to use from the crypto++ DLL must be qualified with _declspec(dllexport) / _declspec(dllimport).
Some of this has been done already, as described in Crypto++ wiki page for Fips dll. It works thru the preprocessor macro CRYPTOPP_DLL, which is defined in the crypto++ header config.h and used in fips140.h.
There is a problem though - not all the algorithms you want are in FIPS and, as you have found, are not exported for use in a DLL. You could modify other headers to add the DLL export/imports but note that the wiki page suggests : "If you really need a DLL, then provide a wrapper DLL that links against the static library.". Rather than wrap every component of every crypto++ algorithm you use, it would be more convenient to encapsulate entire operations into a high level class or function which is then exported/imported from your wrapper DLL.
GCC exports everything by default, which is why shared libraries worked for you on Linux.

You need to link your app against (I believe) cryptopp.lib. This probably comes in separate versions for 32 bit and 64 bit (I believe the names in the import table differ) so make sure you use the right one.
You can tell Visual Studio to do this via Solution Explorer -> Right-click on project name -> Properties -> Linker -> Input -> Additional Dependencies. Then just build again.
Your app will need to be able to find the DLL at runtime, not at link time. If it can't, you will get an error message telling you so when you try to run it. Copying the DLL to the same directory as the executable is what people usually do (and I hope there's no issue using a DLL created by mingw in Visual Studio).

Related

Tensorflow 2.3 unresolved external symbols in machine-generated files when building C++ project on Windows

I was wondering if anyone has had success linking against Tensorflow 2.3 DLL on Windows.
I am trying to integrate some tensorflow functionality in a tiny VS2019 test project to see if I can use tensorflow C++ API at all.
I managed to build tensorflow with MSVC 14.16.27023 and followed the instructions given in the official links:
https://docs.bazel.build/versions/master/windows.html#build-c
https://www.tensorflow.org/install/source_windows
I built .dll and .lib using the following Bazel commands:
bazel build --config=opt //tensorflow:tensorflow.dll
bazel build --config=opt //tensorflow:tensorflow.lib
VS2019 project properties:
add relevant Additional Include Directories
add Additional Library Directories, which is only path-to-tensorflow-source\bazel-bin\tensorflow, where bazel-bin directory is generated by the build system (ie Bazel)
in Linker->Input->Additional Dependencies add generated tensorflow.lib
The source code is tiny and is comprised of a few lines I looked up in Joe Antognini's example:
#pragma once
#define NOMINMAX
#include "tensorflow/core/public/session.h"
#include "tensorflow/cc/ops/standard_ops.h"
int main()
{
tensorflow::Scope root = tensorflow::Scope::NewRootScope();
auto X = tensorflow::ops::Placeholder(root.WithOpName("x"), tensorflow::DT_FLOAT,
tensorflow::ops::Placeholder::Shape({ -1, 2 }));
}
As explained in Ashley Tharp's guide, building right away results in linker errors complaining about unresolved external symbols:
LNK2001 unresolved external symbol "private: class tensorflow::Scope __cdecl tensorflow::Scope::WithOpNameImpl(...
LNK2001 unresolved external symbol "public: static class tensorflow::Scope __cdecl tensorflow::Scope::NewRootScope(void)"...
LNK2001 unresolved external symbol "public: __cdecl tensorflow::Scope::~Scope(void)"...
LNK2001 unresolved external symbol "public: __cdecl tensorflow::ops::Placeholder::Placeholder(...
Here is the explanation from her guide:
The reason this is happening is because you can only expose 60,000 symbols in a dll. This is just some limitation of the dll format. The tensorflow library code has more than 60000 symbols, so as the programmer building this dll (a dll is just a binary file for accessing a library at runtime) you will have to manually indicate which symbols you want exposed if they are not already. Google has chosen some default set, but it may not work for everyone.
And, as suggested in the guide, I went into tensorflow headers and prepended relevant symbols with TF_EXPORT macro, which is your usual DLL import-export pattern:
#ifdef TF_COMPILE_LIBRARY
#define TF_EXPORT __declspec(dllexport)
#else
#define TF_EXPORT __declspec(dllimport)
#endif // TF_COMPILE_LIBRARY
The above-mentioned workaround works for the first 3 errors:
// scope.h
~Scope(); // change to: TF_EXPORT ~Scope();
...
static Scope NewRootScope(); // change to: TF_EXPORT static Scope NewRootScope();
...
Scope WithOpNameImpl(const string& op_name) const; // change to TF_EXPORT Scope...
After I am done editing, I re-run bazel like so bazel build --config=opt //tensorflow:tensorflow.lib, and errors are gone.
However, the issue arises when I try to perform similar manipulation to fix the last remaining unresolved symbol, namely Placeholder. The symbol is located inarray_ops.h, which is a machine-generated file. So whatever I edit inside the file is overwritten and lost as soon as I try to build .lib.
Question: How can I expose symbols that appear in machine-generated files? Pointers in the right direction would be much appreciated, perhaps I'm missing something obvious.
The folder containing dynamic library tensorflow_cc.dll and import library tensorflow_cc.dll.if.lib has also two files:
tensorflow_filtered_def_file.def : contains import symbols
tensorflow_cc.dll-2.params : has all built libraries
now if you have some unresolved symbols when building your app, all you have to do is to rebuild dynamic-library with updated tensorflow_filtered_def_file.def file. To this file you have to add missing symbols, for your sample code, it is:
EXPORTS
??1Scope#tensorflow##QEAA#XZ
?NewRootScope#Scope#tensorflow##SA?AV12#XZ
??0Placeholder#ops#tensorflow##QEAA#AEBVScope#2#W4DataType#2#AEBUAttrs#012##Z
?WithOpNameImpl#Scope#tensorflow##AEBA?AV12#AEBV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std###Z
the rest symbols ...
After you updated .def file, you rebuild dll by calling the following command:
link.exe /nologo /DLL /SUBSYSTEM:CONSOLE -defaultlib:advapi32.lib -DEFAULTLIB:advapi32.lib
-ignore:4221 /FORCE:MULTIPLE /MACHINE:X64
#bazel-out/x64_windows-opt/bin/tensorflow/tensorflow_cc.dll-2.params /OPT:ICF /OPT:REF
/DEF:bazel-out/x64_windows-opt/bin/tensorflow/tensorflow_filtered_def_file.def /ignore:4070
before rebuilding dll/lib remove these files (they are only read-only).
More info here , see rafix07 comment.

Link errors with GraphicsMagick

I downloaded and compiled GraphicsMagick, 1.3.23, Q16, x64, StaticMT version. I had to convert the Visual Studio 7 solution generated by GraphicsMagick's build utility to Visual Studio 2015 format. I linked my project to CORE_DB_magick_.lib and CORE_DB_Magick++_.lib.
When the linker ran, it produced unresolved external symbols when linking InitializeMagick() and DestroyMagick()
1>wtd.lib(WebController.obj) : error LNK2019: unresolved external symbol __imp_DestroyMagick referenced in function "public: __cdecl Wt::WebController::~WebController(void)" (??1WebController#Wt##QEAA#XZ)
1>wtd.lib(WebController.obj) : error LNK2019: unresolved external symbol __imp_InitializeMagick referenced in function "public: __cdecl Wt::WebController::WebController(class Wt::WServer &,class std::basic_string,class std::allocator > const &,bool)" (??0WebController#Wt##QEAA#AEAVWServer#1#AEBV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##_N#Z)
I can't understand why the symbols are not being linked. Any ideas?
Apparently, GraphicsMagick Static versions do not link properly.
What is your project type? I had a similar problem when trying to link the GraphicsMagick libraries to a DLL.
The clue here is that __imp is the function decoration for DLL imports, so you're trying to link with DLL functions.
The problem is that the header magick/common.h, when linked to a DLL project, reads the current configuration of the Visual Studio pre-processor environment to determine which mode the library is in, which is obviously wrong if you're trying to link static libraries into your DLL, for example. In this case, it defines MagickExport to __declspec(dllimport).
AFAIK this is a bug in the library. For proper static build support, magick/common.h needs to do something like read information from the magick/magick_config.h to determine what mode the library was actually built in and define MagickExport appropriately.
Since your library is statically linked, you can fix this by commenting out everything in the define:
#if defined(MSWINDOWS) && !defined(__CYGWIN__)
and replacing it with:
#define MagickExport
#define ModuleExport
#define MagickGlobal

error LNK2019 unresolved external symbol when trying to link dll

I know many people have asked about this error and trust me I've read ALL of them and followed all the steps! But I'm still getting the unresolved external symbol error.
I'm trying to use the dll of lp_solve (a linear programming package) in my c++ code in visual studio 2012.
The error message I'm getting is:
Error 80 error LNK2019: unresolved external symbol _make_lp#8 referenced in function "void __cdecl my_solve(BLAH BLAH)
The function make_lp() is from the lp_solve package and I'm calling it from my_solve() in my code. This error message pops up for each solver function I call. Seems the linker just couldn't find any of the implementation of these functions.
I've done the following
put #include "lp_lib.h" in my source code
put the .dll, .h and .lib files from the lp_solve package in the working directory and
added the path under Linker:General:Additional Library Directories.
added the lib under Linker:Input:Additional dependency
What's wrong?
Thanks for your help!
The problem I had was solved after realizing I downloaded the WIN64 package for lp_solve but my visual studio is using WIN32 as build platform (even though my machine is x86_64).
Using extern "C" may be helpful while including lp_lib.h in your .cpp as follows:
extern "C"
{
#include "lp_lib.h"
}
For more information, please check this link:
http://www.geeksforgeeks.org/extern-c-in-c/

'Unresolved external symbol' errors

I am using an example program that is supposed to allow control of MIDI devices using a protocol called OSC.
What I have done is downloaded the SDK from here: http://mac.softpedia.com/get/Development/Libraries/oscpack.shtml
The 'examples' folder contains a file called 'SimpleSend.cpp'. The code for this is as follows:
#include "osc/OscOutboundPacketStream.h"
#include "ip/UdpSocket.h"
#define ADDRESS "127.0.0.1"
#define PORT 7000
#define OUTPUT_BUFFER_SIZE 1024
int main(int argc, char* argv[])
{
UdpTransmitSocket transmitSocket( IpEndpointName( ADDRESS, PORT ) );
char buffer[OUTPUT_BUFFER_SIZE];
osc::OutboundPacketStream p( buffer, OUTPUT_BUFFER_SIZE );
p << osc::BeginBundleImmediate
<< osc::BeginMessage( "/test1" )
<< true << 23 << (float)3.1415 << "hello" << osc::EndMessage
<< osc::BeginMessage( "/test2" )
<< true << 24 << (float)10.8 << "world" << osc::EndMessage
<< osc::EndBundle;
transmitSocket.Send( p.Data(), p.Size() );
}
I have opened Visual C++ and created a new (CLR console application) project, called 'osctemp'. I copy the code from the 'SimpleSend.cpp' file and paste this into the main cpp file that is created for my project, keeping the following lines of code from the default project file:
#include "stdafx.h"
using namespace System;
I then navigate to the stdafx.h header file and notice that it contains at the bottom the line:
// TODO: reference additional headers your program requires here
...So I obediently move the includes and defines from my main cpp file to here.
I also notice that I need to add the includes to my project so in Windows Explorer I copy the folders 'osc' and 'ip' into my project folder.
Upon running, I receive the following errors:
1>------ Build started: Project: osctemp, Configuration: Debug Win32 ------
1> stdafx.cpp
1> AssemblyInfo.cpp
1> osctemp.cpp
1> Generating Code...
1> .NETFramework,Version=v4.0.AssemblyAttributes.cpp
1>osctemp.obj : error LNK2028: unresolved token (0A00000A) "public: char const * __thiscall osc::OutboundPacketStream::Data(void)const " (?Data#OutboundPacketStream#osc##$$FQBEPBDXZ) referenced in function "int __cdecl main(int,char * * const)" (?main##$$HYAHHQAPAD#Z)
1>osctemp.obj : error LNK2028: unresolved token (0A00000B) "public: unsigned int __thiscall osc::OutboundPacketStream::Size(void)const " (?Size#OutboundPacketStream#osc##$$FQBEIXZ) referenced in function "int __cdecl main(int,char * * const)" (?main##$$HYAHHQAPAD#Z)
1>osctemp.obj : error LNK2028: unresolved token (0A00000C) "public: void __thiscall UdpSocket::Send(char const *,int)" (?Send#UdpSocket##$$FQAEXPBDH#Z) referenced in function "int __cdecl main(int,char * * const)" (?main##$$HYAHHQAPAD#Z)
...(And many more like this)...
1>D:\Temp\OSCTEMP\osctemp\Debug\osctemp.exe : fatal error LNK1120: 40 unresolved externals
What have I missed?
From your problem description I can't find anything about how you link towards the SDK libraries. Have you done so?
To link with the SDK libraries you need one or more .lib files. Even if the SDK is distributed as DLL you need a lib file for the build-time linkage. You should read through the SDK documentation and look for guidelines about link dependencies.
If you can't seem to find any lib-files in the SDK distribution it could very well be that you need to first build the SDK to produce a library and then link towards it. Alternatively, if the SDK comes with a ready VS project you can add it to your solution and set your own project to depend on it (i.e. VS does the work of finding the output lib and linking with it).
Again, if the SDK is of any descent standard, there should be docs about building the SDK yourself if that's necessary.
Good luck.
You're either not pulling in the correct library, or your prototype is not defining the library function correctly according to what's actually in it.

DevIL library files and dependencies

Okay, here's the thing. I have all the IL files I need, namely
DevIL.dll
DevIL.lib
ILU.dll
ILU.lib
ILUT.dll
ILUT.lib
config.h
config.h.in
devil_cpp_wrapper.h
devil_internal_exports.h
il.h
ilu.h
ilu_region.h
ilut.h
ilut_config.h
My project directory looks like this, let's say my project's name is "Project1"
|-Debug---Project1.pdb
|
| |---Debug---[loads of files]
| |
| |---Glut---[OpenGL files]
| |
| |---IL---[all the files mentioned above]
|-Project1---|
| |---image.bmp
Project Folder---| |
| |---[header and .cpp files I made in the project]
| |
| |---[files produced by Visual Studio]
|
|-ipch---[unrelated stuff]
|
|-Project1.sln
|
|-[other files VS created]
I've put all the DevIL files in the IL folder, as mentioned, and I am sure I am using the unicode compatible versions of them, as I am using Unicode Character Set for the project. In my "Additional Dependencies" I have
ilut.lib; ilu.lib; DevIL.lib;
So, the dependencies are there, I know that's not the problem.
After all that, I am still getting linker errors, mainly LNK2019:unresolved external symbol__imp_ for all the IL functions.
What am I missing? It looks to me like maybe something to do with the project properties or the files themselves...maybe I missed a file?
EDIT: Here is the output messages
1>------ Build started: Project: Final Year Project, Configuration: Debug Win32 ------
1>Build started 29/4/2011 12:46:04 pm.
1>InitializeBuildStatus:
1> Touching "Debug\Final Year Project.unsuccessfulbuild".
1>ClCompile:
1> Main.cpp
1>c:\users\xxxx\desktop\final year project 0.2\final year project\main.cpp(152): warning C4390: ';' : empty controlled statement found; is this the intent?
1>c:\users\xxxx\desktop\final year project 0.2\final year project\main.cpp(141): warning C4101: 'alpha' : unreferenced local variable
1>ManifestResourceCompile:
1> All outputs are up-to-date.
1>Main.obj : error LNK2019: unresolved external symbol __imp__ilInit#0 referenced in function "public: static void __cdecl Main::Init(int,char * *)" (?Init#Main##SAXHPAPAD#Z)
1>Main.obj : error LNK2019: unresolved external symbol __imp__ilDeleteImages#8 referenced in function "public: static void __cdecl Main::DisplayScene(void)" (?DisplayScene#Main##SAXXZ)
1>Main.obj : error LNK2019: unresolved external symbol __imp__ilGetData#0 referenced in function "public: static void __cdecl Main::DisplayScene(void)" (?DisplayScene#Main##SAXXZ)
1>Main.obj : error LNK2019: unresolved external symbol __imp__ilConvertImage#8 referenced in function "public: static void __cdecl Main::DisplayScene(void)" (?DisplayScene#Main##SAXXZ)
1>Main.obj : error LNK2019: unresolved external symbol __imp__ilGetInteger#4 referenced in function "public: static void __cdecl Main::DisplayScene(void)" (?DisplayScene#Main##SAXXZ)
1>Main.obj : error LNK2019: unresolved external symbol __imp__ilLoadImage#4 referenced in function "public: static void __cdecl Main::DisplayScene(void)" (?DisplayScene#Main##SAXXZ)
1>Main.obj : error LNK2019: unresolved external symbol __imp__ilBindImage#4 referenced in function "public: static void __cdecl Main::DisplayScene(void)" (?DisplayScene#Main##SAXXZ)
1>Main.obj : error LNK2019: unresolved external symbol __imp__ilGenImages#8 referenced in function "public: static void __cdecl Main::DisplayScene(void)" (?DisplayScene#Main##SAXXZ)
1>C:\Users\xxxx\Desktop\Final Year Project 0.2\Debug\Final Year Project.exe : fatal error LNK1120: 8 unresolved externals
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:01.93
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Since you added the build output, the answer is now easy: your linker errors have nothing to do with DevIL at all.
You need to link to SDL (Simple DirectMedia Layer).
Since SDL has a C interface, and - IIRC - doesn't require that the DLL uses the same heap as the application, the VC8 version of the "Development Libraries" should do fine (even if you use VC10). Just add SDL.lib to the "Additional Dependencies" and you should be fine.
EDIT
OK.
You're either
not linking against the required .lib files (DevIL.lib etc.) or
linking against corrupted/wrong .lib files
At least there is no other explanation I can think of.
The names mentioned in your build log (__imp__ilInit#0 etc.) are correct, and the current "DevIL SDK" (DevIL 1.7.8 SDK for 32-bit Windows) works fine with VC10 (I just verified it).
To assure you're linking against DevIL.lib etc. please put the following in your main.cpp file:
#pragma comment(lib, "DevIL.lib")
#pragma comment(lib, "ILU.lib")
#pragma comment(lib, "ILUT.lib")
To make sure you're linking against the correct version of those files, re-download the whole SDK and try again with the new files.
EDIT 2
Since I got half the reward, I feel I should be more helpful :)
One last thing you can try: enable verbose linker output to check if the linker finds the correct version of DevIL.lib. (If it didn't find any DevIL.lib, you would get an error LNK1104: cannot open file 'DevIL.lib' - and since you're not getting that message, that cannot be the problem.)
To enable verbose linker output, add the /VERBOSE switch (under Configuration Settings -> Linker -> Command Line -> Additional Options).
That will give you a ton of messages. Copy them into your favorite editor, and search for lines containing DevIL.lib. One of the lines should read Searching X:\path\to\DevIL.lib: - that's the path to the copy of DevIL.lib the linker is using. If that's not the path where you copied the files from the SDK you downloaded, you have found the problem.
And if there are no lines containing DevIL.lib, then the linker isn't even trying to locate it. However I've never seen #pragma comment fail, so if you indeed added those lines that almost surely cannot be the case.
BTW: please let me know if you managed to solve this. This is so strange that I really want to know what was going on :)
You need to tell the linker to link against the IL libs.
Project settings, Linker, Input
Make sure the directory the libs are in is in the Additional directorys field too.
I've noticed your config.h.in file should have .win extension because that it is in DevIL-SDK-x86-1.7.8.zip package. And there's no devil_cpp_wrapper.h file also.
Finally i solved this in this way:
Header files
config.h
config.h.win
devil_internal_exports.h
il.h
il_wrap.h
ilu.h
ilu_region.h
ilut.h
ilut_config.h
goes to VC include directory - all in one directory named IL (c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\IL\ by default)
Liblary files
DevIL.lib
ILU.lib
ILUT.lib
goes to lib directory (c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\ by default)
DLL files
DevIL.dll
ILU.dll
ILUT.dll
goes to project dorectory (...\Project Folder\Project1\ in your case)
Then i added liblary files to project by right click on project->Properties->Linker->Input->Additional Dependencies (wrote just name of liblaries like ILU.lib)
In my project I just include IL\il.h, IL\ilu.h and IL\ilut.h
I think you may got wrong files by the way...
Just in case you never got this worked out, or anyone else has the same problem (like I did):
I had downloaded the 64-bit version of DevIL for my 64-bit Windows computer, but Microsoft Visual Studio (I was using Express) was the 32-bit version.
I downloaded the 32-bit version of DevIL and it worked!
I had the same problem. Seems like the pre-built binaries are swapped: I could link to the ones designated as non-unicode but they would utterly fail trying to use my non-unicode strings and return unicode strings. Try to build your own binaries from the source or use a previous version.
you should compare the function signatures that you see in your errors with the signatures you get with depends.exe (depedency walker). If they differ there may be a compiler-issue.
You may then try to compile with :
extern "C" {
// put your devils-include directives here ...
}
Nothing garantied of course , just a suggestion.
You may also check the 'Additional Library Directories' property on your 'Linker\General' page to see if (when used) it points to the right directory for your build (if you also added a path to the standard VC lib-directories their may be a conflict ,use either one but not both).
Another suggestion is to create a new project and do it all over again ,you may have made an ever so little mistake.
Good luck !
I had the same problem.
In my case it was problem with code in all devil`s .h files
#ifdef _WIN32
#if (defined(IL_USE_PRAGMA_LIBS)) && (!defined(_IL_BUILD_LIBRARY))
#if defined(_MSC_VER) || defined(__BORLANDC__)
#pragma comment(lib, "%LIBNAME%.lib")
#endif
#endif
#endif
after second #if code was deactivated.
i added #pragma comment(lib, "DevIL.lib") (and 2 more) into my main.h and linker errors dissapeared.
sorry for my bad english =[
I don't know if this question is still active, but since it has no chosen answer, I'll post this. I had what seems like the exact same problem with DevIL version 1.7.8. To fix it, I rolled back the version to 1.7.7 and used #undef _UNICODE before including the headers and #define _UNICODE afterwards. The project compiled without linker errors and worked without a hitch. On 1.7.8, the libraries seem to all be unicode, or at least they don't seem to support ascii very well. However, this may just be some weird compatibility issue with my computer as it does not seem to be a common problem
It might be that you have to declare some preprocessor variable to actually tell the compiler that you are importing symbol; I mean something related to __declspec( dllimport )
I did exactly as what Sarah said about the 32-bit or 64-bit Visual Studio versions. I'm on a 64-bit computer running a 32-bit Visual Studio 2012. I obtained this error when I used the x64 DevIL files. Getting the x86 version helped. Here's the basic steps I took to ensure it does run:
Right-click your project and go to Properties.
Under C/C++ > General, add DevIL's 'include' folder under Additional Include Directories.
Then under Linker > General, add DevIL's 'lib' folder (it should contain: DevIL.lib, ILU.lib and ILUT.lib) to Additional Library Directories. For x64 it may not contain a lib folder, it may be just the DevIL directory itself (for version 1.7.8 it was that case).
Also in Linker > Input, add those .lib file names into Additional Dependencies.
Now that should be all you need to do in the project properties. In the main.cpp you should include the appropriate header files and it should work when you initialize.
Example:
#include "IL/il.h"
#include "IL/ilu.h"
#include "IL/ilut.h"
int main(){
ilInit();
iluInit();
ilutRenderer(ILUT_OPENGL); //these are just to initialize
}