Click here to Skip to main content
15,879,535 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hello all,

I'm working at my first own big project in C++ for my thesis, so I had never problems like the following before. I'm an absolute beginner.

The goal is to read TIFF images, therefore I'm using Visual Studio 2019 on Windows 10 with GDAL. The code is built from tutorial snippets from Raster API tutorial — GDAL documentation[^]. It was given to me by another programmer and worked for him.

When I try it, there are LNK2019 unresolved external symbol errors like this:
C++
LNK2019	Verweis auf nicht aufgelöstes externes Symbol "_GDALAllRegister@0" in Funktion "_main".	GDAL TEST	C:\Users\Documents\Visual Studio 2019\GDAL TEST\GDAL TEST\Quelle1.obj	1	

Together with the LNK2001 errors which seem to be subsequent to the LNK2019, there are 161 errors. All of them appear in the project's .obj file in row 1.

What I have tried:

I know that these errors happen, when there are library files (or .dlls etc) missing or not linked. So I linked the GDAL library and include paths in the project with the knowlegde I have so far. But it doesn't work.
I guess, there are other files missing but by looking at the errors I found no clue which ones it could be. Also there was nothing in the documentation that helped. How do I find out?

I'm pretty sure that there's no problem with the code.
Hopefully I included all necessary information and there's someone who can help me.


Best regards!
Posted
Updated 23-Mar-21 2:45am
v2

Richard explained the issue(s) to you. I will only add that I really don't like the way this has to be dealt with most of the time. Thankfully, you are using VisualStudio so it is easier. I do this in a two-step approach. First, make sure the libraries you link with are either in a standard library directory for your installation (not preferred) or in a unique place where you installed them which I prefer. I sometimes uninstall the compiler and reinstall it and that can be a problem if you put other libraries in with it. The second step is I make a file with the link commands or add them in with the file that calls the functions of the library. To be more specific, I use #pragma statements to specify the libraries to link with. Here's what one looks like :
C++
#pragma comment( lib, "ExtensionLib19DUS64" )
I like this because you can use conditional compilation to link with different libraries, depending on your situation. For me, the suffixes there all mean something. That one is the VS2019, debug, unicode, static RTL, 64-bit version of my extensions library. With conditional compilation macros I can link with the correct version always. I find this is a major PITA if you do it in the project file itself for every build option.

In your case, I recommend adding a series of pragma statements to specify exactly which libraries you want to link with. The library's documentation should tell you which ones those are. The pragmas can go in almost any module your code compiles, depending on your preference. I put them in a separate header for just the library in question, along with any ifdefs that might affect which library files are needed to link with.
 
Share this answer
 
This is more of way to find your missing function body. It lies somewhere in a .lib file which must be "pathelized" (it's early in my morning and I can't quite come up with the good english expression for this until I've finished my coffee, so please forgive) by adding it's whereabouts to the LIB PATH in Visual Studio project properties. And that's the tricky thing right? You said you've a pile of .libs.

The error message says what is missing but it does so cryptically because it "mangles" function names by appending what-looks-to-be gobbledegook to the end of the actual function name. In your case it's "_GDALAllRegister@0". So what I'd do is use whatever your favorite SEARCH method is and "plugin" (type in) a part of the body of that function as-is-complained-about, targetting your pile of .libs. Try something like "GDALAllRegister" and you should be safe.

Now that you have the path, you can browse to the missing body, line it up in your list of libraries to use during the link, and go to town.
 
Share this answer
 
v3
Comments
Richard MacCutchan 18-Mar-21 5:20am    
Yes, but what should s/he do when s/he gets to town? :laugh:
You need to ensure that the GDAL.lib file (whatever its real name is) is included in the project's linker options. The .dll contains the library code that is used at run time, but the linker needs the .lib file to satisfy all the external references when the project is built.
 
Share this answer
 
Comments
EmmiMSVA 17-Mar-21 9:05am    
Thank you for your response.
There are a lot of .lib files in the lib folder, which I included in the project properties accordingly to instructions and tips on the internet. Still all these errors.
Richard MacCutchan 17-Mar-21 9:28am    
Sorry, but I know nothing about GDAL, you will need to check the documentation.
Thanks for your suggestions. I finally managed to do it.
Here's what helped:
The big mistake was using x86 instead of x64. After changing that, I had to link the include path again. I previously added the gdal_priv.h file to the project. It had to be removed (although I do not have an explanation for that). I then had to add gdal_i.lib to the project.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900