I am trying to build dependencies for a project, currently based on VS2013, with VS2015.
Most of them are building without problems, either as they are or with some patch, but I am totally at a loss with OpenImageIO 1.4.12.
I am passing parameters to cmake and msbuild that set up use of VS2015 for everything, and indeed the generated solution files indicate "vc140_xp" as the chosen toolset.
But at link time I receive error like this one, indicating that somewhere there is a reference to boost libraries built with VS2013:
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc120-mt-1_56.lib' [F:\...\deps\x64\oiio-Release-1.4.12\build\src\libOpenImageIO\OpenImageIO.vcxproj]
Of course I have a bunch of libboost_xxx-vc140-mt-1_56.lib in another place, since I've built them also with VS2015. Also dependencies set up in solution file correctly refer to libboost_xxx-vc140-mt-1_56.lib files and to the correct path, and by doing a FINDSTR in all OpenImageIO build tree I'm not able to find any reference to the older VS version.
But the same command lists a lot of .obj files containing those references, such as (put on multiple lines for better readability):
build\src\libOpenImageIO\OpenImageIO.dir\Release\xmp.obj:/FAILIFMISMATCH:"_CRT_STDIO_ISO_WIDE_SPECIFIERS=0"
libboost_regex-vc120-mt-1_56.lib
libboost_thread-vc120-mt-1_56.lib
libboost_date_time-vc120-mt-1_56.lib
libboost_system-vc120-mt-1_56.lib
libboost_chrono-vc120-mt-1_56.lib
Is it because of these references that link fails looking for different versions of boost libs? Where can these references come from? And how can I get rid of them, since apparently they are nowhere to be found in my configuration?
This problem is in boost itself, not in OpenImageIO, and is caused by the used version of boost being released before VS2015.
As pointed out by kenba in his comment, this answer points to the solution:
Visual Studio 2013 (vs120) asks for wrong boost libraries.
The full explanation, related to an older version of boost and VS, can be found here:
How do I specify, which version of boost library to link to?.
In the case of VS2015, here is how the corresponding lines of code in boost/config/auto_link.hpp should appear:
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1800)
// vc11:
# define BOOST_LIB_TOOLSET "vc110"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1900)
// vc12:
# define BOOST_LIB_TOOLSET "vc120"
# elif defined(BOOST_MSVC)
// vc14:
# define BOOST_LIB_TOOLSET "vc140"
Implementing these lines solved my problem.
Related
I've created a managed C++ log parser application using C++ vectors and Winforms. I want to add multithreading and Boost seemed like a better option than Winforms BackgroundWorker because I want to be able to execute my existing C++ function with each thread. I installed Boost multiple times following multiple different tutorials (lastly this one: https://levelup.gitconnected.com/the-definite-guide-on-compiling-and-linking-boost-c-libraries-for-visual-studio-projects-c79464d7282d) and I still have the same issue when I try to #include <boost/thread.hpp>
Error LNK1104 cannot open file 'libboost_thread-vc143-mt-x64-1_78.lib'
I don't know why it's looking for this library when I have Boost 1_79 installed not 1_78. My .lib file also has "mt-gd-x64" not just "mt-x64". I've already specified the correct file path to the library in Project->Properties->Linker->General->Additional Library Directories. I've also tried installing Boost via Visual Studio 2022 NuGet Package Manager. The lib file in that folder is also slightly off. "vc120" instead of "vc143". I've even tried changing the .lib file name to match the file name in the linker error exactly but when I do that I get more errors like LNK1104 cannot open file 'libboost_chrono-vc143-mt-x64-1_78.lib'
Do I just need to delete all my Boost files and download version 1_78 and try again? Why is Visual Studio looking for the wrong file name when it compiles? Is my #include statement wrong?
I ended up solving this problem by downloading boost 1_78, building it, and specifying that folder instead or the 1_79 folder. If anyone might know why the program was looking for 1_78 instead of 1_79 feel free to respond Also big thanks to George Gkasdrogkas who wrote the tutorial that worked best for me on how to install Boost. Tutorial is linked in the question :)
Apparently anything GUI-related in terms of components involves XML. I cannot go around actually configuring and building wxWidgets from source because of that. I'm new to wxWidgets.
My current setup is on Win10 with MSVC v141 (Visual Studio 2017) with the latest CMake version (currently 3.21).
Inside the config.cmake of the wxWidgets projects (using latest master branch) I see
wx_get_dependencies(EXTRALIBS_XML xml)
I am also calling CMake with -DwxUSE_XML=ON (among other parameters) but this still leads to:
the XML dependency is nowhere to be found
respectively it's not built
Linking then fails with the following error:
LINK : fatal error LNK1104: cannot open file 'wxxml.lib' [C:\Users\...\CMakeBuilds\ef5b5ada-ee42-7735-988a-ae37c735ccff\build\deps\build\wxwidgets\libs\qa\wxqa.vcxproj]
What library is actually wxWidgets using and how do I trigger it's retrieval and accordingly configuration and building? Since I am adding wxWidgets to my CMake project as an ExternalProject component, I would appreciated something in that line of thought. However any kind of information regarding this issue is more than welcome especially since it will shine light on how to configure other features (if I want them in the future) such as WebView.
The wxxml.lib issue is fixed now. While fixing it I also discovered a bug (of sort) in the build system of wxWidgets.
The reason why it failed to build this library in particular was actually quite simple but due to the lack of knowledge in the dependencies of wxWidgets. I thought that wxWidgets, given it depends on XML so much, has its own XML parser. Well, not really. The wxXML component actually uses and underlying 3rd party dependency called EXPAT, which - as you can see in my question - I have deactivated since it was giving me issues during the build (due to the still present problem of not being able to automatically retrieve dependencies).
What I did was to clone the libexpat repository, add it as an ExternalProject, set the variables for the libraries and include directory and pass them onto my wxWidgets project. But there is a catch...
The expat.cmake file looks as follows:
#############################################################################
# Name: build/cmake/lib/expat.cmake
# Purpose: Use external or internal expat lib
# Author: Tobias Taschner
# Created: 2016-09-21
# Copyright: (c) 2016 wxWidgets development team
# Licence: wxWindows licence
#############################################################################
if(wxUSE_EXPAT STREQUAL "builtin")
# TODO: implement building expat via its CMake file, using
# add_subdirectory or ExternalProject_Add
wx_add_builtin_library(wxexpat
src/expat/expat/lib/xmlparse.c
src/expat/expat/lib/xmlrole.c
src/expat/expat/lib/xmltok.c
)
set(EXPAT_LIBRARIES wxexpat)
set(EXPAT_INCLUDE_DIRS ${wxSOURCE_DIR}/src/expat/expat/lib)
elseif(wxUSE_EXPAT)
find_package(EXPAT REQUIRED)
endif()
I would use the *.cmake files of the 3rd party dependencies stored inside <ROOT_OF_WXWIDGETS_PROJECT>/build/cmake/lib to determine which variables I need to set if builtin is selected as the value for the respective library. Since I want to use my own I need sys (e.g. -DwxUSE_EXPAT=sys as a CMAKE_ARGS inside my wxWidgets ExternalProject) and also to pass the headers and libraries accordingly.
Given the file above one would assume that EXPAT_LIBRARIES is required. However after failing to build (yet again) and seeing that the reason was the activated expat build and that it was set as builtin I checked the log in detail and found the following error:
Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.2.6")
Notice the EXPAT_LIBRARY. After passing it (-DEXPAT_LIBRARY=...) my build was complete. For me this is a bug or simply inconsistency between the dependency cmake file and the rest of the wxWidgets project.
It is important to note that I do not retrieve the external dependency through wxWidgets itself (see config.cmake and more precisely the macro wx_get_dependencies(...)). This solves the problem with a basic configuration and build of wxWidgets but if you don't want to tackle every dependency of wxWidgets on your own (why should you?), I recommend looking for a solution where the dependencies (at least the ones you don't want to deal with) are automatically retrieved, configured and build as builtin.
I am pretty experienced writing my own code, but not in C++. I am used to adding .NET assembly references, and I want to get into using C++.
I downloaded a VC++ 6 project presenting a graph algorithm, opened it in Visual Studio 2010 Ultimate and downloaded the required libraries (LEDA .NET assemblies) however, they came with both DLLs and LIB so I thought I would have no problems with the .NET and C++ connection. Also, the LEDA project comes with C++ style .header files, and static libraries, yet frustration persists.
I put my LEDA header files in a directory visible to the project, since I can "Go to definition" of all the custom LEDA data types and see where they are defined in the LEDA include files.
But, I can not compile/link these data types in. The VS finds their very existence repulsive, and refuses to acknowledge they could possibly be found in leda.lib.
Steps I have already taken:
Added additional /LIBPATH path under Properties ->Linker->General
Added explicit lib references under Properties->Linker->Input
Added all the paths containing LEDA header files and libraries to every path location I can find, like include path, reference path, library path.
Copied the DLLs and LIBs to the release folder as well as the base folder of the project.
Added a #pragma comment( lib, "leda" )
Still no joy.
It's quite bad since none of the custom typedefs are recognised the errors balloon to 646 errors.
If anyone is kind enough to offer assistance, thank you.
I can't guarantee this will work but try the following steps (therefore using it's default predefined paths instead of setting your own ones) :
1) Copy *.dll into Windows/System32 or / and (there is some confusion about x64 and x32 default checking in my head :)) Windows/SysWOW64.
2) Copy *.h files into x:\PathToVC2010\include\
3) Copy *.lib files into x:\PathToVC2010\lib\
I'm working on a project that creates a DLL in C for Windows CE 5.0 using STANDARDSDK_500. The project is relatively simple with just one C source file. What I've noticed is that when I clean and build the project using Visual Studio 2005, it fails to create my Import lib. When I tell Visual Studio to rebuild it, it correctly creates the import lib.
Turning on verbose linking, I discover that in the failure case (clean and build) CVTRES.exe is discarding my functions, like so:
Invoking CVTRES.exe:
/machine:thumb
/verbose
/out:"C:\...\Temp\lnkC7E.tmp"
/readonly
/windowsce
".\standardsdk_500 (armv4i)\release\WLTBApi.res"
Microsoft (R) Windows Resource To Object Converter Version 8.00.50727.42
...
adding resource. type:VERSION, name:1, language:0x0409, flags:0x30, size:892
Discarded '.idata$4' from coredll.lib(COREDLL.dll)
...
Discarded WLRegisterStartupApp from WLTBApi.obj // my functions! Oh noes!
...
This discards all of my functions, which causes the linker to not create an import lib because there are no exported functions.
I figured that the input was the .res file mentioned in the commandline - WLTBApi.res. This file is identical in the intermediate directory after trying to compile both the working way (rebuild) and the non-working way (clean. build).
So, my first question is: what are the other inputs to the CVTRES.exe program so that I can find discrepencies between the two builds?
Second: what other troubleshooting techniques would you recommend?
Additional Info - I thought perhaps the .obj files were additional inputs - they differ between the builds. I now believe that they are outputs of CVTRES.exe. If anyone knows whether or not I'm correct in this, let me know.
Okay, so I found a solution, but I'm terribly dissatisfied with it. I discovered that the project I was building had a Dependency, but one that wasn't actually a dependency. In other words, the project, WLTBApi was building a DLL, and had a dependency configured, WLTBApiLib, but it wasn't actually using any of the output of that project. By removing the dependency, the problem went away.
I'd still love to know more about how to find an actual answer to what was going on, but maybe this answer will help someone else in the future.
I'm trying to use the new OpenCV 2.0 API in MS Visual C++ 2008 and wrote this simple program:
cv::Mat img1 = cv::imread("image.jpg",1);
cv::namedWindow("My Window", CV_WINDOW_AUTOSIZE);
cv::imshow("My Window", img1);
Visual Studio returnes an unhandled exception and the Console returns:
OpenCV Error: bad flag (parameter or structure field)
(Unrecognized or unsupported array type) in unknown function,
file ..\..\..\..\ocv\opencv\src\cxcore\cxarray.cpp, line 2376
The image is not displayed. Furthermore the window "My Window" has a strange caption: "ÌÌÌÌMy Window", which is not dependent on the name.
The "old" C API using commands like cvLoadImage, cvNamedWindow or cvShowImage works without any problem for the same image file. I tried a lot of different stuff without success.
I appreciate any help here.
Konrad
As I just commented, imread isn't working for me either. A little googling shows other people having the same problem; I guess it's a bug in the library code. For now, here's a hacky workaround:
IplImage* img = cvLoadImage("lena.jpg");
cv::Mat lena(img);
cvReleaseImage(&img);
This way, you can at least use the C++ API for the rest of your stuff.
There's help for this issue.
The solution is, that the usual proposed opencv library files in the linker are not working properly. Instead try to use the debug library files by this:
In Visual C++:
go to Project->Properties (or Alt-F7)
Configuration Properties->Linker->Input->Additional Dependencies
replace the usual
" cv210.lib cxcore210.lib highgui210.lib" by
" cv210d.lib cxcore210d.lib highgui210d.lib" - which are the debugging libraries.
The OpenCv 2.0 API commands should work now.
I had the same problem described above which turns out to be caused by the settings of the linker.
I found the answer in another thread,
OpenCV 2.3 and Visual Studio 2010.
To repeat it here:
Properties of your project (right click on it)
C/C++
General
include directory add the < your directory >\OpenCV2.3\include\opencv2, < your directory >\OpenCV2.3\include\opencv and < your directory >\OpenCV2.3\include
Linker
General
List item
Input
Add all the libs like opencv_core230d.lib opencv_highgui230d.lib and so on...
Once I've done the above, I can run imshow and imread + all other cpp functions seamlessly! OP's problem has probably already been resolved, but hopefully this will be useful to other people who are led here looking for the same solution.
Are you sure you added the whole path starting from /home/.... I had the same problem as you but when I added the whole path, things work out pretty well. The whole path had to be added despite the fact the path exists in the include files.
imread in openCV unlike Matlab does not return an error when file/folder is not found - instead it returns a null matrix, which in turn is reflected as an error during imshow.
Also, imread does not look for image files in the included folders or the workspace. So, specify the entire path whenever possible.
Please take a note of this for future references.
Firstly, you'd better compile your own version OpenCV.
I had the same error with the build (I got from Sourceforge), and solved by compiling my own version in debug and release versions.
And make sure you change the original system env variable PATH to the new build folder build/bin, then you could build and run the imshow() in Debug mode.
I believe this might be related to unicode.
Try the macro _TEXT()
For example:
cv::Mat img1 = cv::imread(_TEXT("image.jpg"),1);
Unicode in Visual C++ 2