I have configured VS2017 to build Linux C++ by remote building on a Linux Mint VM.
I tried a simple C++ program and it compiles and executes fine, the thing is that now I need to add a generated protobuf source and the linking fails constantly.
On the Linux VM the protobuf generated files are building correctly and I was able to execute the gRPC examples.
The errors I get when I build from VS2017 are a lot of:
undefined reference to 'google::protobuf::internal'
and there is also this one
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Application Type\Linux\1.0\Linux.targets(262,5): error : Illegal characters in path.
I think this is a VS2017 remote compilation configuration issue, but I don't know what could it be.
Has it happened to you? Do you know how to solve this issue?
Thanks
SOLUTION: I the project properties go to Linker > All Options > Library dependencies and add: protobuf;pthread;grpc++;grpc
This explains the "Illegal characters in path" message.
Does protobuf link to any libraries on the Linux system? Assuming you're not using CMake, have you added the libraries andtheir path(s) to the Visual Studio project - Library Dependencies and Additional Library Directories.
This might help with specifying libraries.
Related
I have a project that I build with CMake, which is composed of a library black.dll and an executable black.exe that depends on the DLL. The DLL in turn depends on libz3.dll which is an external dependency.
When I build from the command prompt using CMake I cannot run the executable because of the error "The application was unable to start correctly (0xc0000142)". The external dependency libz3.dll is correctly copied into the executable directory.
But, when I build the project from Visual Studio 2019 (making it use CMake under the hood as well), everything works properly (when I copy libz3.dll into the executable directory).
I've looked at the two executables with Dependency Walker to understand what's the different between the two but there are no differences (both show errors of missing strange libraries such as API-MS-WIN-CRT-RUNTIME-L1-1-0.DLL but in the case of the executable built with VS it seems to not be a problem).
I've also checked to be building for the correct architecture: both the executable, the library and libz3.dll are built for x64.
What can I check to understand what's going on?
I've recently decided to try out PostgreSQL as the database platform for some C++ development I'm working on. I decided to use libpqxx as the connection library for my project, and quickly found out this would be an uphill battle to do from VS 2015 on a Windows 10 machine.
After much teeth-gnashing and nail-biting, I have gotten libpqxx to compile on Windows 10.
This leaves me with the following directory structure
Per libpqxx's documentation, I also placed a copy of libpq.dll in my project's executable directory. Please note: I have done this for both debug and release builds, tried to build both, and ended up with the same result.
All the tutorials I've seen seem to indicate that the library can be used after linking it and simply #including pqxx/pqxx, so I set up a small project to do just that. I receive the error:
fatal error C1083: Cannot open include file: 'pqxx/pqxx': No such file or directory
When attempting to build the project. I have also tried this will both debug and release builds, to no avail.
Here is a screenshot of my linker settings.
Does anyone have any suggestions for how I might be able to link and use this library from Visual Studio 2015?
As Sami Kuhmonen pointed out, this was not actually a linker error, but a compiler error. I needed to include an actual header, which Visual Studio needed to be able to find. After adding the correct folder (C:\libpqxx\include in my case) to Visual Studio's "additional include directories" setting under C\C++ -> General per drescherjm's suggestion, the program compiles just fine.
For future reference:
I did also run into unresolved external linker errors after solving the initial issue. This is because you need to make sure to also link to ws2_32.lib and libpq.lib. You also need to copy some other DLL files that libpq also relies on into your libpqxx lib folder. On my system, I believe these were ssleay32.dll, libeay32.dll, and libintl-8.dll. These files reside under the root of the PostgreSQL install. The DLL step is mentioned under libpqxx's INSTALL.txt file, however I believe it stated that the DLLs resided one folder under where I actually found them.
I have also faced same issue. Then I realized that I was building ,my application as a 32bit. I changed the target to x64 and it compiled successfully
I cloned a project from github to my computer and I'm trying to compile it but I'm getting a crazy amount of errors regarding references to libraries and stuff. I uploaded the project from another computer and it works just fine in that computer. Here are the errors I'm getting:
There are more errors but these are enough. As you can see the issue is within the included libraries (which are static), so I'm not sure what I'm missing here, because the linking to the wininet library and such are fine.
Maybe its an inconsistency between x86 and x64? I dunno.
The path to the c++ compiler:
C:\Program Files
(x86)\mingw-w64\i686-5.2.0-win32-dwarf-rt_v4-rev0\mingw32\bin\c++.exe
Path to library
C:\Program Files
(x86)\mingw-w64\i686-5.2.0-win32-dwarf-rt_v4-rev0\mingw32\include\wininet.h
I followed these steps to configure this environment:
-Downloaded netbeans
-Downloaded mingwin
-Downloaded msys
Its weird because when ctrl + click the wininet.h and variable types and everything it directs me to where they're declared, however the environment can't locate them.
If you need more information please tell me.
Thanks!
There's no such thing as "the WinInet" library that you can download. This is all part of the Windows SDK. LPVOID for instance is defined after you include <windows.h>
I have written a simple program in C++ that uses the boost filesystem library to organize some files. I am using the Visual Studio 2013 Express for Windows Desktop IDE. I would like my program to run on other computers without an installer or anything else. The user should be able to just download the program and click on it.
I built my program in Release mode and it works on my computer. When I tried to deploy on another computer, the error I got was MSVCP120.dll is missing. To fix this I right-clicked on my project, clicked properties, then Configuration Properties > C/C++ > Code Generation, and I changed the Runtime Library from Multi-threaded DLL (/MD) to Multi-threaded (/MT). Now my program won't compile properly because of this build error:
Error 1 error LNK1104: cannot open file
'libboost_filesystem-vc120-mt-s-1_55.lib' C:\Users\inspection\Desktop\sortFile\Project1\Project1\LINK Project1
I looked in the following folder:
C:\Program Files\boost\boost_1_55_0\libs\filesystem\build\msvc-12.0\release\link-static\threading-multi
and I could not find libboost_filesystem-vc120-mt-s-1_55.lib, though I could find libboost_filesystem-vc120-mt-1_55.lib. The file names are close, they only differ by an '-s' term located after the '-mt' term.
How can I statically link the boost filesystem library so that my whole program runs as a standalone executable, without another user having to install anything?
Boost needs to be recompiled to match your new runtime library setting. The filename of the Boost library indicates the settings it was linked with, and the Boost auto-link code automatically updated the needed filename to match your new settings. In this case, it quite accurately indicates that you need a Boost lib which was compiled with a static stdlib link.
This is what I have done:
Download the 1.54 zip file from the boost website
Extracted/copied it to C:\Program Files (x86)\Boost
Inside Visual Studio I have set the include libraries to: C:\Program Files (x86)\Boost\boost_1_54_0\boost_1_54_0\
(This seems to work fine for getting the compiler to accept the libraries)
Now the bit i'm having problems with- linker:
Inside Visual Studio I have set the linker include directories to: C:\Program Files (x86)\Boost\boost_1_54_0\boost_1_54_0\libs\
When I compile my project I get:
fatal error LNK1104: cannot open file 'libboost_date_time-iw-mt-sgd-1_54.lib'
EDIT Have built the boost binaries using the answer below. However I now have these files:
libboost_date_time-vc110-1_54.lib
libboost_date_time-vc110-gd-1_54.lib
libboost_date_time-vc110-mt-1_54.lib
libboost_date_time-vc110-mt-gd-1_54.lib
libboost_date_time-vc110-mt-s-1_54.lib
libboost_date_time-vc110-mt-sgd-1_54.lib
libboost_date_time-vc110-s-1_54.lib
libboost_date_time-vc110-sgd-1_54.lib
but still no
'libboost_date_time-iw-mt-sgd-1_54.lib'
EDIT: Think I have found the problem:
http://lists.boost.org/Archives/boost/2004/08/70114.php
OK, here's the problem: originally we had one Intel toolset:
"intel-win32" which created the library suffix "iw" (note no version
number!), and this is what the auto-link header currently searches
for.
However people have started adding versioned Intel toolsets, which
means that we now produce an ad-hoc mixture of library names, some
with compiler-version suffixes and some without, the autolink code
could handle either form, but as it's not psychic it can't handle
both :-(
Solution is to #define BOOST_ALL_NO_LIB
On a 64bit system you should build boost in Program Files, not Program Files(x86) the boost automatic library include does not handle the redirection correctly. Alternatively you can manually manage the library inclusion... but I would highly recommend against it.
Also a reminder that you need to build boost in all the flavors and bitnesses you are going to use. See How to use Boost in Visual Studio 2010 for a good example of how to do so.
In an administrator visual studio command prompt go to the boost directory
run bootstrap.bat
run b2 --toolset=msvc-10.0 --build-type=complete architecture=x86 address-model=64
wait for b2 to finish building
EDIT:
As it turns out the iw in that library refers to the intel compiler... to use that with boost and visual studio you'll need to follow the directions from Intel.