I am trying to use MIDL compiler with cmake and that's what I came to.
In the similar questions people sujjest to use add_custom_command, but I suppose it is outdated since simply adding the IDL file to the list of files does the trick.
However there are problem with this approach:
Output files are not added to the list of files, so the compiler doesn't compile them.
1.1. Adding files manually doesn't work because cmake can't find them (since they don't exist)
Output files are created in the intermediate directory, where cmake doesn't really gives access to.
It changes default names of the output files in the project settings (e.g. %(Filename).h instead of %(Filename)_i.h for header files).
So my question is did somebody encountered these issues and if so how to fix them?
Using add_custom_command is undesirable because Visual Studio doesn't treat it as a normal IDL file, so you have to setup everything manually.
I have been successfully testing an image processing library (https://github.com/libvips/libvips) in a C++ project in VS2017. I am new to C/C++ and I have been following the documentation here which describes the C way of using the library. There are features I would like to try in the C++ API, but the C++ API needs to be built with the same compiler as my project. According to the author:
It's slightly awkward to set up under Windows. The problem is that C++
does not have a ABI, so you must use exactly the same C++ compiler for
your whole project. This means the libvips C++ win binary (built with
g++) won't work with MSVC C++.
You need to copy the libvips C++ API source code into your own project
and build it with your own code. It's just a few files and pretty
simple to incorporate:
https://github.com/libvips/libvips/tree/master/cplusplus
I have made several attempts to build the minimal set of files but I have not had any success.
My steps so far:
Create a C++ console app in VS2017, set to Debug and x64
Extract the 'vips-dev-8.10' folder from vips-dev-w64-all-8.10.6.zip to where the project file is (this contains all the built .dll files, .lib files, .h files etc.)
Extract 'cplusplus' folder from 'libvips-master.zip' to where the project file is (this has all the project source files including the cplusplus folder which is the part I have to build per the above explanation)
Add the following folders to Project > Properties > C/C++->General > Additional Include Directories
C:\Projects\ConsoleApplicationVIPS3\ConsoleApplicationVIPS3\cplusplus\include\vips
C:\Projects\ConsoleApplicationVIPS3\ConsoleApplicationVIPS3\vips-dev-8.10\include
C:\Projects\ConsoleApplicationVIPS\ConsoleApplicationVIPS\vips-dev-8.10\lib\glib-2.0\include
C:\Projects\ConsoleApplicationVIPS\ConsoleApplicationVIPS\vips-dev-8.10\include\glib-2.0
Add the 5 .cpp files from the cplusplus folder into the project Source Files folder and Add them in the project tree.
Build the project.
As a result I get the following errors:
I haven't written any code yet. I thought I should just be able to point to the .h include files and compile the required C++ files. It's not clear to me what else I might need to add, but it definitely seems like I don't understand the correct procedure to build the project. I watched some videos on C++ compilation like this one but I cant see where I went wrong.
Any thoughts would be much appreciated.
EDITS 3-Jun-21
I have made some changes. I have instead extracted the exact version of the library according to the suggestion by #Frank, and I also discovered the usefulness of the compiler output window, thanks #Alan Birtles.
I am still getting errors, but I am not clear why. The first error is:
E0020 identifier "VImage" is undefined
Which is odd because I have added the folders to Project > Properties > C/C++->General > Additional Include Directories, and one of them is ..\cplusplus\include\vips which contains VImage8.h
And the Output window shows
Any further advice would be appreciated!
Situation
I learned a lot over the last year, but this is something I just could not wrap my head around. Project is C++. CMake 1.15.2. Visual Studio 2015.
I converted a whole Solution *.sln file with cmake-converter and wrote FindXXX.cmake Modules for all external *.libs defined in the *.vcxproj files.
Everytime I encountered an error: unresolved external I added the corresponding Target Sometarget::somecomponent to the target_link_libraries(ConsumingTarget ... ) call.
Now I have a build that works and produces no errors. Some executables say something along the lines of:
"Execution of code cannot be continued because somecomponent.dll is not found..."
I have
An original .sln file that produces executables only requiring .lib files
A CMake generated .sln file that produces executables requiring .dll files
Working FindXXX.cmake files which add_library(XXX::yyy UNKNOWN IMPORTED)
They find the headers and the .lib files (.dll files are not existing/intended/needed in the original VS .sln)
They create the corresponding Targets for all .lib files
Consuming Targets which target_link_libraries(ConsumingTarget PRIVATE XXX::yyy)
"A working build"
An error "before starting the main function".
What I have tried
I have tried defining an OBJECT Library and adding this to the sources of ConsumingTarget and removing Sometarget::somecomponent from the target_link_libraries call. CMake Doc on Object Libraries
I have tried reading and understanding the difference between module and library. Even the CMake documentation on imported Libraries couldn't help me understand my problem.
I have tried reading and understanding the difference between linking a static and shared library.
My Assumptions
Adding the imported library is done wrong by me.
Reason: DependenciesGui.exe shows different dependencies for the cmake-generated-executable and the original-sln-executable but the linker calls (shown in VisualStudio 2015) seem to be the same.
Whole Program Optimization in the CMake File does not work the same way it does in the original .sln file although the Flags are activated at all levels described in this answer.
Reason: compiling with the original file I noticed warning C4505: 'foobar': unreferenced local function has been removed - I don't seem to get those warnings with the cmake-generated build.
subassumption: Functions which won't be called are optimized away, thus removing the necessity for the .dll file.
I expect/hope for
ConsumingTarget.exe to run without asking for somecomponent.dll
another explanation on imported targets and how to link libraries where .dlls should not be necessary.
an explanation on how to analyze/compare the two binaries regarding their symbols(?) and map the seen information to CMake commands. (I am using DependenciesGui.exe to look for dependencies in the .exe file)
Possible reason for failure
One executable had no /DELAYLOAD... directive after conversion with cmake-converter. Opened Issue. Question Title still holds.
Edits:
1: Added possible reason for failure
I've been encountering a strange bug in Visual Studio 2010 for some time now.
I have a solution consisting of a project which compiles to a static library, and another project which is really simple but depends on this library.
Sometimes, in the last days extremely frequent, after Rebuilding the Solution or just compiling it with 1-3 changed source files, I get the following error:
2>LINK : fatal error LNK1181: cannot open input file 'thelibrary.lib'
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========
Where compiling thelibrary.lib was a success without any errors or warnings.
I have tried cleaning the solution, but that doesn't always work.
What is wrong here?
In Linker, general, additional library directories, add the directory to the .dll or .libs you have included in Linker, Input.
It does not work if you put this in VC++ Directories, Library Directories.
I can see only 1 things happening here:
You did't set properly dependences to thelibrary.lib in your project meaning that thelibrary.lib is built in the wrong order (Or in the same time if you have more then 1 CPU build configuration, which can also explain randomness of the error). ( You can change the project dependences in: Menu->Project->Project Dependencies )
Go to:
Project properties -> Linker -> General -> Link Library Dependencies set No.
I recently hit the same error. Some digging brought up this:
http://support.microsoft.com/kb/815645
Basically, if you have spaces in the path of the .lib, that's bad. Don't know if that's what's happening for you, but seems reasonably possible.
The fix is either 1) put the lib reference in "quotes", or 2) add the lib's path to your Library Directories (Configuration Properties >> VC++ Directories).
I had the same issue in both VS 2010 and VS 2012.
On my system the first static lib was built and then got immediately deleted when the main project started building.
The problem is the common intermediate folder for several projects. Just assign separate intermediate folder for each project.
Read more on this here
I solved it with the following:
Go to View-> Property Pages -> Configuration Properties -> Linker -> Input
Under additional dependencies add the thelibrary.lib. Don't use any quotations.
I had a similar problem in that I was getting LINK1181 errors on the .OBJ file that was part of the project itself (and there were only 2 .cxx files in the entire project).
Initially I had setup the project to generate an .EXE in Visual Studio, and then in the
Property Pages -> Configuration Properties -> General -> Project Defaults -> Configuration Type, I changed the .EXE to .DLL. Suspecting that somehow Visual Studio 2008 was getting confused, I recreated the entire solution from scratch using .DLL mode right from the start. Problem went away after that. I imagine if you manually picked your way through the .vcproj and other related files you could figure out how to fix things without starting from scratch (but my program consisted of two .cpp files so it was easier to start over).
I'm stumbling into the same issue. For me it seems to be caused by having 2 projects with the same name, one depending on the other.
For example, I have one project named Foo which produces Foo.lib. I then have another project that's also named Foo which produces Foo.exe and links in Foo.lib.
I watched the file activity w/ Process Monitor. What seems to be happening is Foo(lib) is built first--which is proper because Foo(exe) is marked as depending on Foo(lib). This is all fine and builds successfully, and is placed in the output directory--$(OutDir)$(TargetName)$(TargetExt). Then Foo(exe) is triggered to rebuild. Well, a rebuild is a clean followed by a build. It seems like the 'clean' stage of Foo.exe is deleting Foo.lib from the output directory. This also explains why a subsequent 'build' works--that doesn't delete output files.
A bug in VS I guess.
Unfortunately I don't have a solution to the problem as it involves Rebuild. A workaround is to manually issue Clean, and then Build.
I don't know why, but changing the Linker->Input->Additional Dependencies reference from "dxguid.lib" to "C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x86\dxguid.lib" (in my case) was the only thing that worked.
Maybe you have a hardware problem.
I had the same problem on my old system (AMD 1800 MHz CPU ,1GB RAM ,Windows 7 Ultimate) ,until I changed the 2x 512 MB RAM to 2x 1GB RAM. Haven't had any problems since. Also other (minor) problems disappeared. Guess those two 512 MB modules didn't like each other that much ,because 2x 512 MB + 1GB or 1x 512 MB + 2x 1GB didn't work properly either.
For me the problem was a wrong include directory. I have no idea why this caused the error with the seemingly missing lib as the include directory only contains the header files. And the library directory had the correct path set.
You can also fix the spaces-in-path problem by specifying the library path in DOS "8.3" format.
To get the 8.3 form, do (at the command line):
DIR /AD /X
recursively through every level of the directories.
I had the same problem. Solved it by defining a macro OBJECTS that contains all the linker objects e.g.:
OBJECTS = target.exe kernel32.lib mylib.lib (etc)
And then specifying $(OBJECTS) on the linker's command line.
I don't use Visual Studio though, just nmake and a .MAK file
I had the same error when running lib.exe from cmd on Windows with a long argument list. apparently cmd.exe has max line length of about 8K characters, which resulted that the filenames at the end of this threshold got changed, thus resulting in bad filename error.
my solution was to trim the line. I removed all paths from filenames and added single path using /LIBPATH option. for example:
/LIBPATH:absolute_path /OUT:outfilename filename1.obj filename2.obj ... filenameN.obj
I found a different solution for this...
Actually, I missed comma separator between two library paths. After adding common it worked for me.
Go to: Project properties -> Linker -> General -> Link Library Dependencies
At this path make sure the path of the library is correct.
Previous Code (With Bug - because I forgot to separate two lib paths with comma):
<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
Code after fix (Just separate libraries with comma):
<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**;..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
Hope this will help you.
In my case I had the library installed using NuGet package (cpprestsdk) AND I falsely added the lib to the Additional Dependancies in the Linker settings. It turns out, the package does it all for you.
The linker then tried to find the library in the library path and of course could not find it.
After removing the library from the Additional Dependencies everything compiled and linked fine.
Not quite the answer to OP's question as I am using CMake with Visual Studio as a generator but I personally also just encountered the same issue (I am using Visual Studio toolchain, but not the IDE to build stuff).
My fix was target linking the directory of the directory of the libraries (I had a few) before target linking the library.
//Works
target_link_directories(MyExe PRIVATE /out/of/scope/path/to/lib)
foreach(X IN LISTS LIBSLISTNAMES)
target_link_libraries(MyExe ${X})
endforeach()
//Throws cannot open cannot open input file error
foreach(X IN LISTS LIBSLISTNAMES)
target_link_libraries(MyExe /out/of/scope/path/to/lib/${X})
endforeach()
Not sure what is happening under the hood, but maybe VS IDE has equivalent setting somewhere?
I've also experienced this problem. For me the dependencies were properly set, but one of the projects in my solution wasn't selected for building in the configuration (VS 2022 pro).
I eventually figured out thanks to output in Build -> Clean Solution that mentioned one of the project in dependency chain being disabled. Interesingly enough, when trying to build the disabled project it wouldd not properly build its dependencies.
In the solution were two projects A and B. Building B requires A.lib, and somewhere along the line, the solution was cleaned.
Later, for testing purposes it was desired to build B alone, and the error was mistakenly taken as
cannot open input file 'B.lib'
instead of what it actually was
cannot open input file 'A.lib'
So burning the candles at both ends in order to comprehend why the project B build process would delete its own library!
I created a bin directory at the project_dir level, then created a release/debug directory inside the bin folder, which solved the problem for me.
We have a large project using VS2008 and boost 1_42. I'm trying to upgrade to VS2010 and boost 1_44. I installed VS2010 and boost 1_44 and converted the project. Now I am trying to build, and everything compiles, but fails when linking:
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-1_42.lib'
I have changed the include and lib directories to point to the new boost 1_44 files and I have renamed the old boost 1_42 directory.
Why is the linker still looking for a vc90-1_42 file, when it is only using 1_44 headers? Is there a way that I can determine WHY the linker wants this file? The linker obviously thinks it needs the file, but why?
I have cleaned the project and I am re-building to ensure any old build files are erased.
I've run into exactly this problem a couple of times too. It's usually been some old temporary files but like in your case cleaning didn't always do the trick straight away. Does your project include any static libs that might have been built with 1.42?
Something you can try which may or may not be helpful in tracking down your issue:
Rename the old boost directory back to it's original name
Clean the solution
Under C/C++->Command Line->Additional Options add "/showIncludes"
Under Linker->Command Line->Additional Options add "/verbose:lib"
Rebuild all
Then when you build you'll be able to see at which point 1.42 headers are included, etc. in the output window. Somehow doing this helped me in tracking down where the problem was.
Along with changing the lib directory, you need to change the name of the boost library. That's in the Linker | Input section of the project settings.
Your added comment makes it clear that the dependency on the Boost 1.42 library was being created indirectly by another library that hadn't been rebuilt.
For this you basically have two choices: either add that library as a project to your main solution, and make sure it has enough dependency information that it'll be re-built when you upgrade Boost, or use the /Zl compiler switch when you build your library. This tells the compiler you're building a library so you do not want to embed library dependencies like this.
Boost uses
#pragma comment(lib)
command to inform the linker of libraries it needs to link with. It is not an error. If Boost says you need it, it's likely you do.
On How can I find out why the linker wants this file?
There are programs which will go through your app and dlls/libs and report the content of manifests and what the binaries report they depend on. You could then scan the report for the unexpected libraries being included. We used this mainly to find libs including the previous version of the VC runtime.
Have not used the one we had in about 5 years though, now if only I could remember the name of the app!
DependancyWalker (depends.exe) will allow you to see dependancies of dll/exe but not static libs.
You could open each binary as a 'file' in MSVS and look at the manifest content by hand, but I imaging this would be a bit painful. I've not tried this with a static lib.