I am trying to create a VS2019 project with ImageMagick (Magick++) as a statically linked library.
I have followed the directions from https://github.com/ImageMagick/ImageMagick-Windows.
In the wizard configurator I requested:
Build Type: Static Multi-threaded runtimes
Kept most settings to the default beyond that.
In my project I have set the header file include path to include:
C:\developer\ImageMagick\ImageMagick\
C:\developer\ImageMagick\ImageMagick\Magick++\lib
I have added library paths of:
C:\developer\ImageMagick\VisualMagick\lib
and I have added the relevant 3 library files for debug and release.. debug shown below:
CORE_DB_Magick++_.lib
CORE_DB_MagickCore_.lib
CORE_DB_MagickWand_.lib
In code I have:
#include <Magick++.h>
...
char szImageMagickLIBDirectory[MAX_PATH];
strcpy_s(szImageMagickLIBDirectory, MAX_PATH, "C:\\developer\\ImageMagick\\VisualMagick\\lib");
Magick::InitializeMagick(szImageMagickLIBDirectory);
Unortunately I get many LNK2001 unresolved external symbol errors during linking.
example:
LNK2001 unresolved external symbol UnregisterGRADIENTImage <myProjectName> <my_project_path>\CORE_DB_Magick++_.lib(static.obj) 1
Does anyone have information on how to setup a VS project for ImageMagick:x64-windows-static library use?
My backup plan (as you may deduce from my vcpkg notation) will be to use GraphicsMagick.
Well I feel a right idiot!
My mistake was thinking that the all the additional LIBs had been compiled into the 3 key LIBs commonly referenced and used by ImageMagick. That simply isnt the case! Gah! The very simple answer is to add all thirty odd static libraries to the project! Thats all!
I honestly thought I was dealing with some complex Linker settings issue, when the problem was simply my arrogant assumption!
I must now consume coffee to stave off the mind altering dumbness I feel!
Related
I am getting a linker error, I'll post it at the bottom. The goal is only to build the example SSL client from boost.
The overall question is just to find the simplest c++ way to download some xml from https://classic.wowhead.com/item=19351&xml
Edit: The problem has evolved as I've continued to work on it. I now realize that I had no idea how to use a static or dynamic library or how either worked. I know a little now.
I've built OpenSSL following this youtube video verbatim and it seems to have built properly. https://www.youtube.com/watch?v=PMHEoBkxYaQ
I'm now using the shorter example https://stackoverflow.com/a/7577229/2247872 and finally got it working which has helped enormously in identifying where the other errors are. I had to be really careful that I was using x86 Debug for everything and then added D:\out\lib\x32\Debug\include to my include directories, d:\out\lib\x64\debug\lib to my linker libraries, and libssl.lib and libcrypto.lib to my additional dependencies. One thing that was helpful is that if #include wasn't underlined by Visual Studio I knew I at least had the include directory set correctly.
I've made two copies of my program, one uses static linking the other dynamic linking. To get the dynamic linking one to work I had to copy the libssl-3.dll and libcrypto-3.dll files in to the same place as my executable.
Right now I'm still fighting with boost on the static one.
#include <boost/beast/core.hpp> //all of these are fine
#include <boost/beast/http.hpp>
#include <boost/beast/version.hpp>
#include <boost/asio/connect.hpp>
#include <boost/asio/ip/tcp.hpp>
#include <openssl/ssl.h>
#include <openssl/conf.h>
//#include <boost/beast/ssl.hpp> //this line is giving me 196,429 errors.
//#include <boost/asio/ssl/error.hpp> ////this line is giving me 196,429 errors.
//#include <boost/asio/ssl/stream.hpp> //this line is giving me 196,429 errors.
Original Post:
I found similar questions on SO but the names of the OpenSSL libraries have changed and I need a current answer to setting up my MS Visual Studio 2019 project properties properly.
I do not need to build these files (I don't think). All I want to do is get the boost example here https://www.boost.org/doc/libs/master/libs/beast/example/http/client/sync-ssl/http_client_sync_ssl.cpp working.
Question 1: Which of the options from https://wiki.openssl.org/index.php/Binaries or https://slproweb.com/products/Win32OpenSSL.html do I want? For example I don't understand the difference between a pre-compiled build without external dependencies to VS2019 or the one on that bottom pre-compiled build with external dependencies to VS2019. My original choice was the one from the 2nd website that said 1.1.0L "this is the standard version for x64".
I chose the option to install the library files in the Windows System directory. I see files named
c:\windows\system32\libcrypto.dll
c:\windows\system32\libssl-1_1x64.dll
I added C:\Windows\System32 to my path environment in windows and restarted the computer.
In VS project properties:
My C/C++ --> General --> Additional Include Directories are:
d:\cpp\boost_1_72_0
d:\OpenSSL-Win64\include
My Linker --> General --> Additional Library Directories
d:\openssl-win64\lib
d:\openSSL-win64\lib\VC
d:\openSSL-win64\lib\VC\static
c:\windows\system32\
d:\opensll-win64\StaticDLLsIGuess (this is a directory I put files in from a 2nd attempt to solve the problem, by downloading two files from https://indy.fulgan.com/SSL/ but they need in ".a"
d:\cpp\boost_1_72_0\stage\lib
In Linker --> Additional Dependencies I tried to list:
libssl.lib
libcrypto.lib
But when those were there I got a different, simple error saying "libssl.lib" couldn't be found which I found baffling as pretty much my entire computer is in my build options. So why that is happening is question 2. Same thing for
c:\windows\system32\libssl-1_1x64.dll
I know that file is there, but when I put libssl-1_1x64.dll in additional dependencies I get a link1104 error that it's not found even though c:\windows\system32 is in additional library directories.
Question 3 is what libraries do I actually need? There are libraries in my system 32 directory, libraries in D:\OpenSSL-Win64\lib, and libraries in D:\OpenSSL-Win64\lib\VC
This is the actual error I'm getting but I cannot interpret what linker error messages actually mean.
Severity Code Description Project File Line Suppression State
Error
LNK2019 unresolved external symbol _CONF_modules_unload referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::~do_init(void)" (??
1do_init#openssl_init_base#detail#ssl#asio#boost##QAE#XZ) PreparedParser
D:\cpp\PreparedParser\PreparedParser\PreparedParser.obj 1
Edit: I am still in the process of trying to fix this myself, and I'm realizing that part of the problem is that I had no understanding of the difference between a dynamic and static library. I'm trying to figure that out now. Also, https://www.youtube.com/watch?v=PMHEoBkxYaQ is a video on how to compile OpenSSL and I'm doing that.
Edit April 18 11am: Side questions: If I download a .lib from somewhere, how do I put it in my program? Do I #include the lib file? Do I add it to additional dependencies? How do I know what functions are in it? How is it different for .dlls?
Probably the most asked question on GLFW ever. But I've tried everything I can think of and after 3 hours of googling I give up.
What I've been able to understand is that this error occours when:
The compiled code for function makes a reference or call to symbol, but that symbol isn't defined in any of the libraries or object files specified to the linker.
That means I must have simply failed linking the library as I understand.
Ok so located in: "C:\dev\MyVSProjects\MyWorld\dependencies\OpenGL\GLFW\lib-vc2015"
is my glfw3.lib file.
Inside of my solutions Property Pages I set "Additional Library Directories" to "$(SolutionDir)dependencies\OpenGL\GLFW\lib-vc2015" which is where the above file is located relavtive to the .sln file.
Then finally in the linker I set Additional Dependencies to: "opengl32.lib;glfw3.lib;%(AdditionalDependencies)"
Thats pretty simple, and I just dont understand how that cannot be linked correctly.
Im using glad in my project btw and it works correctly, also both the glfw3.h and glad.h files are found. (And yes im including glad.h first).
Yet every GLFW function gets the unresolved external symbol error.
So my question is why am i still getting these unresolved external symbol linking errors.
Alright so it turns out I did do everything correctly. The 64-bit binaries simply does not work with Visual studio 17...
If your experienceing the same issue simply get the 32 bit binaries.
I am trying to get the ARPACK library to run on VS2010.
I would like to use the C++ wrappers
provided by ARPACK++ (some background - i need to get eigenvalues and eigenvectors of huge matrices). There is a very good tutorial on the subject here.
Following the
tutorial i've managed to compile the fortran code using g77 on mingw, i successfully generated
the dll and lib as described. The problem arises when trying to link my visual studio project to the library.
The way i'm trying to link is as follows:
I've made a simple VS2010 C++ console app
i've added the the folder containing ARPACK++ libraries to my "additional include folders"
i've added the lib file to "Additional dependencies"
i've added the directory containg the lib file to my "Additional library directories"
Despite these settings when i try to compile this short test code:
#include "stdafx.h"
#include "arrsnsym.h"
int _tmain(int argc, _TCHAR* argv[])
{
ARrcNonSymStdEig<float> prob(100, 4L);
printf("Bok!");
return 0;
}
I get an error saying:
>arpackcpp.obj : error LNK2001: unresolved external symbol scopy_
1>arpackcpp.obj : error LNK2001: unresolved external symbol snaupd_
1>arpackcpp.obj : error LNK2001: unresolved external symbol sneupd_
I do not understand why the linker can't find the mentioned methods. Inspecting
the .def file generated by the dllwrap utility does indeed mention all these functions
so i am fairly sure they should be available. Still, i feel i'm missing something obvious.
UPDATE (got it working!):
It turns out that i was trying to link a 64 bit program to a 32 bit library, when switching
to x86 in the Configuration settings AND including the generated def file in Configuration Properties -> Linker -> Input -> Additional definition file, it worked for 32bit (however i needed 64). The final solution that worked for me was to cross compile it for Win64 using MinGW and gfortran on linux. That worked surprisingly well and produced a dll to which i could link from a 64bit C++ app in VS. I think i should now go write a tutorial on how to do this :)
My guess is that this is a name-mangling scheme issue. In fortran, it is not well defined what name the symbols will have in the object file's symbol table. For example, a routine named foo could end up in the symbol table as foo,FOO,foo_,foo__ and so on. These days, I don't know of too many compilers that use double underscores (with g77 being the exception). I'm assuming the ARPACK++ wrappers are assuming a single underscore. The solution here is to tell the compiler to use single underscores in the symbol names (with g77, that means using -fno-second-underscore). Note that gfortran is a newer (still supported) open-source fortran compiler which does single underscoring by default. You might want to try to build your code using that compiler as well. (It might produce more optimized output than g77.)
I have a solution with two projects on VS2010.
The main project references and depends on the second one, which is built as a static library. The second one uses a static third-party library that is not build within the solution, but is only referenced in the second project's linker settings.
If I try to generate the solution, VS fails and indicates that he didn't find the third-party library. I do not understand why, since the second project's compiled static lib is big enough and seems to "contain" the 3rd-party library.
So far, I see only two solutions to my problem, which I would rather avoid:
Add the 3rd-party library to the main project's linker settings
Include the whole 3rd-party library in my solution and compile it with
Is there any other way to resolve this problem?
EDIT : The problem occurs when compiling the main project, the compiler outputs : LINK : fatal error LNK1104: cannot open file 'wxbase29u.lib' (I'm using wxWidget in my second project)
EDIT2 : I put the -verbose option for linking on, and it seems like the references to the 3rd-party library actually still exists in Project2.lib :
Searching ..\MyAppConfig\Bin\Win32\Release\MyAppConfig.lib :
"public: static void __cdecl ConfigWindow::Open(void)" (?Open#ConfigWindow##SAXXZ) found
Referenced in main.obj
Loaded MyAppConfig.lib(configWindow.obj)
/DEFAULTLIB:wxbase29u processed
/DEFAULTLIB:wxbase29u_net processed
/DEFAULTLIB:wxbase29u_xml processed
/DEFAULTLIB:wxregexu processed
/DEFAULTLIB:wxexpat processed
/DEFAULTLIB:wxjpeg processed
/DEFAULTLIB:wxpng processed
/DEFAULTLIB:wxtiff processed
/DEFAULTLIB:wxzlib processed
...
...
LINK : fatal error LNK1104: cannot open file 'wxbase29u.lib'
Funny thing is that I don't even use the other wxWidgets libraries in Project2, but visual studio seems to be searching for all of them though :/
Here's how you should setup your project:
Project 1 (main)
Additional dependencies: Project2.lib
Project 2
Additional dependencies: ThirdParty.lib
Build order: Project 2 -> Project 1
If your project is setup like that and it does not link, then it just means the path to your libraries isn't correctly set (under "Additional include directories"). So just make sure that your project additional dependencies are correctly set and that the include directories point to the place where the libraries you need are located.
I was advised by some of you not to long ago to use FreeImage as a library for image processing in C++.
I now have some trouble in getting the library to work (still relatively new here).
I've tried loading the various vcxproj and sln tiles and they gave me a blank project. Since there isn't any installation instructions provided for that, I gave up on making it a visual studio solution.
I next tried the old-fashion way of compiling the source code using the Makefile and then adding "FreeImage/Source" to the linker. While the IDE does not raise any red flags when I call functions declared in FreeImage.h, it gave me a bunch of "error LNK2019: unresolved external symbol" during compilation, as if the functions do not exist. What I suspect is that the IDE could not find the .cpp files that define the said functions, but I still get that same problem when I added FreeImage/Source/FreeImage to the linker.
Now when I directly included some of the .cpp files (i.e. Plugin.cpp and FreeImage.cpp) for a test, I get even more unresolved external symbol errors as well as things like "inconsistent dll linkage" for this within... for example FreeImage.cpp:
const char * DLL_CALLCONV
FreeImage_GetVersion() {
static char s_version[16];
sprintf(s_version, "%d.%d.%d", FREEIMAGE_MAJOR_VERSION, FREEIMAGE_MINOR_VERSION, FREEIMAGE_RELEASE_SERIAL);
return s_version;
}
So, I am totally stuck. What am I doing wrong? I felt I've followed the adequate steps in adding library dependencies, such as adding the specific folders that are immediate parents to the relevant .h and .cpp files in C/C++ -> General -> Additional Included Directories and Linker -> General -> Addition Library Directories.
Some help will be greatly appreciated!
Using FreeImage v3.15.3 I had no problems converting the VS2008 project to VS2010.
Also the building worked as expected. But when I linked to the static lib, I got some unresolved externals. First I tried al kinds of tricks setting /MT /MD linking, but that did not solve these linking problem.
After reading Some Newbie's comment I dug into freeimage.h. There I found a macro switch FREEIMAGE_LIB that controls the calling conventions of the function.
Use a #define FREEIMAGE_LIB before including the freeimage.h file. That way you can easily static link to FreeImage.lib