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 :)
Related
I have checked the updated code from the weibsite: http://sourceforge.net/projects/clipsrules/
When I build the CLPSStactic project, there is an error displayed in the output window:
..\clipscpplib.cpp(281):error C2664:
"EnvAddRouterWithContext": cannot convert parameter 4 from "int (__cdecl *)(void *,const char *) to "int (__cdecl *)()""
Notes：
I use the VS2012 version
Using VS2012 open the CLIPS.sln(in the folder named "Installer")
has errors in updating to vs2012(CLIPS.vdproj, CLIPSSource.vdproj). But the CLIPS's source code has generated in the folder ../Source/CLIPS.
CLIPSDynamic and CLIPSWrapper can be compiled without errors.
I want to know why this error come out, is it related to the VS version or anything else? How to solve this?
Thank you!
#Gary Riley
If you have time, please take a look at this. Thank you!
You're using the wrong projects/solutions. Download the latest commit (r281). The solution folders in the microsoft_windows directory that you want to use are CLIPS_MVC_2010, CLIPS_MVC_2013, Examples_MVC_2010, and Examples_MVC_2013. Since you're using Visual Studio 2012, you'll probably want to use the 2010 directories. The instructions in the Advanced Programming Guide specifically reference these directories. Don't use anything in the Installer directory. You'll need to copy the CLIPS source code files from the core directory to the microsoft_windows/Source/CLIPS directory since these aren't replicated in the repository.
I have solved this problem by myself. There's the details:
Copy the "router.h" and "router.c" files from the folder "core" (http://sourceforge.net/p/clipsrules/code/HEAD/tree/)
to the folder "microsoft_windows/Source/CLIPS", and delete both origin files in the folder "../CLIPS".
Don't copy all the files in the folder "core" to "CLIPS". it won't make the CLIPSStatic project built successful either. It seems there are problems in "aggenda.h" or "aggenda.c" of the folder "core".
I think the problem is that the "router.h" and "router.c" generated by the project CLIPS in the folder named "Installer" isn't the newest version.
If you have check the code from the same website, and used the same version VS. you may encounter this problem too. And this manner can help you to solve the problem.
Greetings, what I'm trying to do is to port an existing Windows application to Linux using CMake with CMakeLists, which I generated with the vcproj2cmake Script (https://github.com/sixman9/vcproj2cmake).
With the CMakeLists.txt and CMake I was able to successfully port a VS 2005 project to VS 2010. Now I try to port the same VS 2005 project to Linux, so that I can edit it with KDevelope.
The project itself is small and I think it would be easier to just create a new project and copy all relevant files (if that would work), the problem is, that it's not only one project but many, hence I was looking for a way to port a project in an as simple as possible way.
In Linux I was able to create a CMakeLists.txt using the vcproj2cmake script. The next step would be creating a KDevelope project using CMake. And this is where I'm stuck.
Everytime I try to run CMake I get the following error:
CMake Error at CMakeLists.txt: 196 (set_property) :
set_property could not find TARGET Test_Project. Perhaps it has not yet been
created.
Test_Project: installing /root/Desktop/Test_Project/vs8/CMakeLists. txt rebuilder (watching /root/Desktop/Test_Project/vs8/Test_Project. vcproj)
Configuring incomplete, errors occurred!
See also “/root/Desktop/Test_Project/vs8/CMakeFiles/CMakeOutput.log”.
I searched for a solution or an approach for quite a time now, but the only results that I get are project-specific, or at least I think they are.
Content of the CMakeLists.txt from line 196:
set_property(TARGET Test_Project PROPERTY PROJECT_LABEL "Test_Project")
v2c_rebuild_on_update(Test_Project "${CMAKE_CURRENT_SOURCE_DIR}/Test_Project.vcproj" ${CMAKE_CURRENT_LIST_FILE} "vcproj2cmake.rb" ".")
include(${V2C_HOOK_POST} OPTIONAL)
Perhaps there are more efficient ways to port many projects form Windows to Linux, I'm open for any suggestion.
It is a bit difficult to help without having your project - since you are using a third party tool to convert a VC project you should ask the author of that tool. :D
If you have many projects which you are going to maintain, I suggest that you select one where you can create a cross platform (Windows/Linux) CMake config for which you can reuse for other projects.
Most of the config should be the same for all platforms you are building for - the difference should be which generator is used and what libraries to link in the final executable (if you are building one that is). The generator is specified when running cmake.
In my opinion you should try an out of source build with the following structure:
/$COMMON_DIR/CMakeLists.txt
/CMakeLists.txt
/src/
/build/
/build/vcX
/build/generate_vcX.bat
/build/linux
/build/generate_linux.sh
$COMMON_DIR should contain the CMake code you expect to be common for all you projects - like a function to create a static library for a module which searches for files in /src and another function which can be used to add an executable for certain platform.
The CMakeLists.txt in the root of your project (repository, I assume) should call the functions defined in $COMMON_DIR and possibly add some project specific defines or link flags.
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 am trying to upgrade an old solution to use VS2010 (VC100).
I have it setup so that stdafx.cpp will create a precompiled header stdafx.pch from stdafx.h. Then all the other .cpp files that include stdafx.h are instructed to use the precompiled header.
These posts helped me get this far:
Visual C++ Precompiled Headers errors
Precompiled Headers
Now all is fine when I build in release mode. However when I try and build in debug mode I get a whole heap of errors saying:
Error 1 error C2859: [removed]\debug\vc100.idb is not the idb file that was used when this precompiled header was created, recreate the precompiled header.
I believe that this .idb file is an intermediate debug file created by Visual Studio.
Why am I getting this error? In other words why did it not use this .idb file when it created the precompiled header?
I'm not sure what further information you need to be able to give me answer so just ask if there is more information that I need to provide.
Thanks to a colleague I got the answer.
The problem was that stdafx.cpp had Debug Information Format set to Program Database (/Zi) where as all the other files had it set to Program Database for Edit and Continue (/ZI).
Changing them all to Program Database for Edit and Continue (/ZI) and doing a full rebuild solved the problem.
I guess the upgrade screwed it up somehow.
I've hit this error with VS2005 when compiling a project where the $(ProjectName) is different from the actual output file of the project (i.e. Linker > Output File isn't set to the default of $(OutDir)\$(ProjectName).exe but to something else, e.g. $(OutDir)\$(ProjectName)-custom_postfix.exe)
In this case, and apparently only when doing a Rebuild-Project-Only, the vc80.pdb seems to be looked up wrongly.
What helped me was to additionally set C/C++ > Output Files > Progam Database File Name to $(IntDir)\$(TargetName).pdb. (Instead of the default vc80.pdb)
select Disable for the Debug Information Format in the Properties page for stdafx.cpp, then go back and select Inherit from parent worked for me.
Maybe your release build is configured to write file [removed]\debug\vc100.idb instead of [removed]\release\vc100.idb? Check the project settings for your release build and make sure there are no hardcoded path components like that.
Here's how I just fixed this error on Visual Studio 2008:
Background:
I have a solution that contains two sub-projects.
One project compiles the .dll;
One project compiles the .exe that used this .dll;
The .exe project is dependent on the .dll project;
Problem: I had both of the projects dumping their output into the same directory, i.e. both "OutPutDirectory" and "IntermediateDirectory" set to write to a common directory in the root, "../$(ConfigurationName)".
Cause of error:
The cause of this error was that when the .dll project was compiled, it created the precompiled header (*.pch) in the same directory as the .exe directory, and when the .exe project was compiled, it promptly overwrote the precompiled header (*.pch) from the .dll project.
The fix:
To fix this, I changed the "IntermediateDirectory" for both sub-projects to "temp", so that the temporary files (including the precompiled header files) were written to different directories.
I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny