I am using Visual Studio 2017, and building in x64. I have 2 libraries linked to my solution file, flann, and opencv. I can build the release mode but in debug mode everything is messed up! The problem is with opencv library, and I have double checked the library directories, everything seems to be correct! What am I doing wrong then?!
Here is one of the errors I am getting:
LNK2001 unresolved external symbol "private: void __cdecl cv::String::deallocate(void)" (?deallocate#String#cv##AEAAXXZ)
Found the problem! under solution --> properties --> C/C++ --> Preprocessor --> Preprocessor Definition: I had WIN32 as one of the definition while building in X64! Removing that fixed my problem!
Related
In our project team we applications for micro-controller targets with arm-none-eabi-gcc. For running our testrunner we compile using the native cc compiler.
In our project team most use a Linux os, but some us a windows os (for reasons). The issue we run into is that we use the C11 keyword _Static_assert. When compiling on Linux it works, but when compiling under windows we get the following error: error LNK2019: unresolved external symbol _Static_assert referenced in function {}
This is due to the reason that the default MSVC compiler implements ANSI C89 which doesn't support the _Static_assert symbol. MSVC - C standards support
It also specifies that adding the /std:c11 or /std:c17 compiler options enable the support for _Static_assert.
We already have enabled --enable_platform_specific_config for other reasons.
Simply adding the build:windows --copt="/std:c11" to the .bazelrc solves the issue but also breaks the normal application build because arm-none-eabi-gcc compiler doesn't support the /std:c11 compiler flag.
Question: How can i add the /std:c11 compiler flag so that it only propagates to the native msvc compiler and not to the rest of my build targets?
When using MSVC for host builds (when building a tool that emits source code which is then #include'd, for example protocol buffer compiler) add build:windows --host_copt="/std:c11". When using MSVC for test builds, add test:windows --host_copt="/std:c11". Don't put it in build:windows --copt because that will apply even when running builds to the target.
I am currently working on a Universal Windows Platform (C++/Cx) in Visual Studio Enterprise 2019 16.10.3. Part of this project requires the use of OpenCV to generate an image. I implemented this in a C++ console application and was able to get it working perfectly. Using this tutorial as a guide, I downloaded and installed OpenCV 4.5.2 for Windows and configured it within my console application via the Visual Studio project properties.
Everything worked correctly until I moved the code into my UWP project. I copied the exact same settings for OpenCV from my console application into this UWP project, but when running it on Debug x64, I am receiving an "Unable to activate Windows Store app...'The target process aborted before activation completed." error when I try to run it. In the Debug console, it states that "A dependent dll was not found" but does not specify what DLL anywhere. If I run it on Debug x86, I get four LNK2019 errors that look like this, in addition to a warning about OpenCV being an x64 library but being ran in an x86 application:
unresolved external symbol "void __cdecl cv::error(int,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,char const *,char const *,int)" (?error#cv##YAXHABV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##PBD1H#Z) referenced in function "public: class cv::Vec<unsigned char,3> & __thiscall cv::Mat::at<class cv::Vec<unsigned char,3> >(class cv::Point_<int>)" (??$at#V?$Vec#E$02#cv###Mat#cv##QAEAAV?$Vec#E$02#1#V?$Point_#H#1##Z)
In short, I am using the exact same code and project settings for OpenCV between the two projects, and it works in a console application but not a UWP application. I have tried to use an OpenCV package installed through NuGet instead, but it throws 11 errors similar to the one above. Does anyone know what may be wrong? Visual Studio is able to read the OpenCV library because the header files I am using appear under the External Dependencies folder in my Solution Explorer.
I am open to using a different method of OpenCV installation if that will work better, or even an alterative to OpenCV entirely if necessary.
Any help is much appreciated. I'm having link errors when trying to use HDF5 libraries installed using vcpkg with Visual Studio 2019 on Windows 10.
I installed HDF5 1.12.0 on Windows 10 using vcpkg:
PowerShell: .\vcpkg install hdf5 hdf5:x64-windows
I then attempted to use Visual Studio 2019 to build my project that uses HDF5, but I keep getting the following LNK2001 errors.
unresolved external symbol H5T_IEEE_F64BE_g
unresolved external symbol H5T_STD_I64BE_g
unresolved external symbol H5T_C_S1_g
unresolved external symbol H5T_NATIVE_INT_g
unresolved external symbol H5T_NATIVE_DOUBLE_g
I tried to solve this by directly adding the additional library directories that are under the vcpkg/packages/ for HDF5, SZIP, and ZLIB, that were automatically installed as part of the HDF5 installation step given previously, and I also added the library files to the additional dependencies in the order prescribed by the HDF5 documentation:
hdf5_hl.lib
hdf5.lib
szip.lib
zlib.lib
But I still have the unresolved external symbol errors.
All those symbols are prefixed with H5_DLLVAR. As such you need to explicitly set the preprocessor definitionH5_BUILT_AS_DYNAMIC_LIBif you are not using CMake and only the MSBuild integration vcpkg provides. You could also open and issue with vcpkg since it should embedded that definition into the correct hdf5 header if the library is built dynamically.
The vcpkg command that I used installs the dynamic version of the libraries. Instead I installed the static version of the libraries using:
./vcpkg install hdf5:x64-windows-static
No manual inclusion of the library directories or libraries themselves is needed. Just be sure to run this command as well (when first installing vcpkg):
./vcpkg.exe integrate install
Once that was done, Visual Studio 2019 was able to properly use the HDF5 libraries for my project and the linker error was gone (binary produced).
Hope this helps someone in the future!
Attempt to link with Visual Studio 2019 an old Visual Studio 2008 x86 project using Gsl library v1.13, I got this error on link step:
LNK2019 symbole externe non résolu __imp____iob_func référencé dans la fonction _gsl_error
Options are same from Visual Studio 2008 project and already tried these points in this link :
unresolved external symbol __imp__fprintf and __imp____iob_func, SDL2
If someone has idea and can help?
Thank you
__iob and __printf are symbols contained in the stdio library.
It seems to me that the standard libc library is not statically linked to your new executable.
Try to this:
Configure the new project to statically link the libc library
The constitution of the project is:
Main Executable (AA)
refers to intermediate static lib (BB)
refers to gsl v1.13 static lib build ten years ago it seems (CC)
https://ftp.igh.cnrs.fr/pub/gnu/gsl/
I may be looking for the option to statically link the main executable (AA) with the standard libc library under Visual Studio 2019 but can't find accurate information out of this https://learn.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-160.
Just so as not to mislead my protagonist to link statically, can you confirm to me that it is necessary to link with the standard library (AA) , (BB) or (CC) ?
I am upgrading our TFS 2012 system to TFS 2015, and have an issue with one of our upgraded XAML builds. The build compiles >200 projects without an issue, however two project produce the following SGEN error. It appears the build engine attempts to build the project using the x86 4.0 version of the mscorlib, but I think it needs the x64 version. The build server has both x86 and x64 versions of the .Net 4. 0 framework installed.
From the build Log:
Built $ Change-Management/.../Helpers.csproj for default targets.
WARN: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
(1605): There was a mismatch between the processor architecture of
the project being built "AMD64" and the processor architecture of the
reference
Warn: "C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll", "x86".
This mismatch may cause runtime failures. Please consider changing
the targeted processor architecture of your project through the
Configuration Manager so as to align the processor architectures
between your project and references, or take a dependency on
references with a processor architecture that matches the targeted
processor architecture of your project.
WARN: CSC:Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor
ERROR: SGEN: An attempt was made to load an assembly with an incorrect format:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll
I have tried the SO solution described here but it did not work. I attempted to install the Widows 8 SDK (the server is 2008 r2).
Ideas?
You may try to go to the Build|Configuration Manager menu item, and change the platform for your project from "Any CPU" to "x86" to see whether the error persists:
Find the project in Build|Configuration Manager.
Select the in the platform drop down.
Select x86 from the "New Platform" drop down and select "Any CPU" in
the "Copy settings from" drop down.
Click OK.