I have a Remote Solution for my Raspberry Pi (A remote Linux system) in Visual Studio Community 2017 which consists of two C++ projects.
As Project_B is dependent on Project_A. I added the suiting project dependency under Solution->Properties->Common Properties->Project Dependencies.
All the includes from Project A in Project B declared as following:
#include "../Project_A/header.h"
(They should be correct as it compiles)
When I build Project_B Project_A compiles and is linked (according to the output view) and Project_B is compiled but the linker crashes as it cannot find the definitions of the functions from Project_A.
Sometimes, the whole IDE crashes and needs a restart.
Compiling and linking only Project_A works fine.
As a workaround I have copied all files from Project_A to Project_B and modified the includes accordingly and removed the project dependency.
Like that, it works.
However I would like to have an working, clean solution for linking two project on a remote linux system in Visual Studio.
Thanks in advance.
4-Apr
Thinking about this, I wonder whether I need to take a step back.
A Visual Studio project takes a bunch of source files and creates one (we'll leave it simple for now) target, e.g. an executable. It also creates several intermediates along the way, most importantly the object files.
So how do you use the funtionality of one project in another? The simplest way is source include which works just like you've done with the headers, add the sources from projectB to projectA. Not the most efficient solution and it can get messy but it will work.
The most common approach is to build projectB into a library. Then projectA, which creates the executable, links to the projectB library.
To create projectB's library, set the project type to static library and have projectA link to it; this is what my original answer addressed.
===============
Solution->Properties->Common Properties->Project Dependencies allows you to specify the build order, i.e. projectA depends on projectB so projectB should be built first. It does not create cross-project references for compiler and linker.
You must tell projectA where to find the headers and binaries of projectB on the Pi. In the case of headers you can, as you have done, use relative paths but it would be more general to specify the location of projectB files in Additional Include Directories under C/C++ - General in the VS project properties.
For libraries, you must specify Library Dependencies under Linker - Input in the project properties and Additional Library Directories under Linker - General. Alternatively, for projects in the same solution, you can add a Reference to projectB under projectA.
Related
I implemented the SFML library nightly build to my Visual Studio 2013, because the original one is not compatibile with this VS version. I done everything what is needed (added directory to include folder in both Debug and Release, added directory to .dll files), but it can't find the files in program. What else should be done to make this library work? Or should i consider changing Visual Studio to 2010?
You haven't given really to much information so I am just really guessing as to what the problem is.
added directory to .dll files
But that sounds like your problem right there. You don't add the directory that the .dll files are in to your project. The only directories you need to add to the project are the include directory and the library directory.
But anyways I am assuming you are using dynamic linking since otherwise you wouldn't be dealing with .dlls. Now different IDE's require that you place the .dlls in different spots but since you are dealing with VS2013 you need to copy whatever .dlls that you are using into the same folder where your program's compiled executable is (The .exe file).
Another option is to link statically instead of dynamically which I generally prefer to do on small projects but it is really up to the developer which he prefers.
When you link statically you don't need to include any .dlls. What you will need to do is recompile SFML's sources and make sure to build the library so it produces the static library files (They should be named something like sfml-graphics-s-d.lib for debug and sfml-graphics-s-d.lib for release).
Add that library directory which contains the static library files to your project and then link to them .lib files in VS's input window (Remember that -d is for the debug build).
Next you will need to add SFML_STATIC to your preprocessor options on both the release and debug build.
After that you are good to go and don't need to include the .dll files with your project. And again whether you choose to link dynamically or statically is really up to you and the project you are working on but for small projects I would suggest linking statically.
For learning purposes, i wanted to create a static library, a "package" of the lib files used in opencv to then link it against my app "opencvuser". Doing so, i get tremendous amounts of erros. (LNK2005 and LNK2019)
My Setup:
Project: staticLib
I've created a static library application without precompiled headers.
Under librarian i've put D:\OpenCV248\build\x64\vc10\staticlib as an additional library
directory. And I've specified all available .lib files as additional
dependencies. (opencv_core248d.lib, opencv_imgproc248d.lib, opencv_highgui248d.lib, ...) Source
Project: opencvuser
I've added C:\OpenCV240\build\include as an additional include directory
Then i've listed "staticLib" under "Properties -> References"
What i expect: Now i should get the same functionallity, as i would add the opencv lib files instead of my built staticLib.lib is my expectation correct?
What i've checked so far:
All Projects are x64
Runtime-Library is set in both Projects to "Multi-threaded Debug"
Anyone knows if the Runtime-Library setting on the static libraries are set to "Multi-threaded Debug"?
You are getting those linker errors because the OpenCV libs you are trying to use were statically linked against the CRT. In your project, you are dynamically linking to CRT and these things won't mix. I would recommend that you don't try to create a "package" of all the OpenCV libs and instead just link to the specific libs you need where you need them.
But I am also going to show you how to solve your problem:
You need to recompile OpenCV without statically linking to the CRT.
You can check out the OpenCV documentation for instructions on how to compile OpenCV using CMake and Visual Studio 2010.
When you run CMake, after you pressed the "Configure" button, look for an option called "BUILD_WITH_STATIC_CRT" and disable it. Then you can press "Generate", open the solution with VS2010 and compile OpenCV.
In your VS2010 project, use the following settings:
In the "opencvuser" project configuration, under Librarian, additional library directories you need to add the path to where the .lib files that you built are located. For me, it's in "c:\opencv248\mybuild\lib\Debug\".
Under Additional Dependencies, you need to include all the OpenCV lib files (opencv_core248d.lib, etc). I also needed to include Comctl32.lib and zlibd.lib because if I didn't I would get some linker errors.
Here are the dependencies I put in:
opencv_calib3d248d.lib
opencv_contrib248d.lib
opencv_core248d.lib
opencv_features2d248d.lib
opencv_flann248d.lib
opencv_gpu248d.lib
opencv_haartraining_engined.lib
opencv_highgui248d.lib
opencv_imgproc248d.lib
opencv_legacy248d.lib
opencv_ml248d.lib
opencv_nonfree248d.lib
opencv_objdetect248d.lib
opencv_ocl248d.lib
opencv_photo248d.lib
opencv_stitching248d.lib
opencv_superres248d.lib
opencv_ts248d.lib
opencv_video248d.lib
opencv_videostab248d.lib
Comctl32.lib
zlibd.lib
Also, in the "opencvuser" project you need to add an empty .cpp file. If you don't add this file, the solution will be empty and Visual Studio won't compile it. I just added a file called "dummy.cpp" to the project. That file is completely empty. Don't put a "main()" function in it because it will collide with the main function in the other project and you will get an error.
In the "staticlib" project, under Linker->General, Additional library directories, you need to include the path to the opencvuser.lib file. For me, it's "..\debug". Also, under Linker->Input, Additional Dependencies, you need to add the "opencvuser.lib" file.
Set project dependencies
You also need to make sure that the projects are built in the right order (first opencvuser, then staticlib). To do this, right-click on the solution and choose Properties. In that window, under Common Properties->Project dependencies, make sure that "opencvuser" does not have a dependency on "staticlib", but "staticlib" must have a dependency on "opencvuser".
That's it, now your project should work. Here are the contents of the two files, and the project running.
Consider visual studio solution with multiple projects, some source files are used in several projects.
I'm currently including source files used in multiple projects in each project, but that leads to same source file being compiled for each project. Is there any way to specify single project to be a one that builds files, and link against built objects in all the other projects.
I'm aware of option to create a static lib, but I would like to know if it is possible to specify dependencies directly between the projects in solution - like you can do by writing makefile.
Search has revealed single question on the subject from 2010, but there is no suitable solution there:
How to use the same obj files in different projects in the same solution
You can specify project dependencies (http://msdn.microsoft.com/en-us/library/et61xzb3(v=vs.80).aspx) but in order to use the same source between the projects you'll need to create a static lib or a dll and link with that. You can set up these configurations in the project settings as well so you won't have code that shows the linking, it's all done in compile/linking statements
One thing you might consider is to create a solution where you have multiple projects, and you properly set the building dependency of each your projects such that the 'base project' will always built before other projects depending it it are built.
as you mention Static lib is the best project type to do that. group all your common file in a static lib project, and on your DLL or exe project create a dependency to the lib by using the "add dependency" option you should get with a right click on your project in the VS solution explorer pane.
take care about 1 thing : if you create a cascade of dependency between Libs they will become bigger and bigger (the last lib of the chain will contain all the symbol of all the other ... a kind of cat of the .obj file....)
I am working with Visual Studio 2012.
My Solution has 3 projects
projectA
projectB
projectC
and the Hierarchy is like
projectC depends on projectB which in turn depend on projectA. There is a main function in projectC and no main in projectB and projectA.
The errors that i am getting are:
error LNK1561: entry point must be defined projectA
error LNK1561: entry point must be defined projectB
I have tried changing in the
Configuration Properties -> Linker -> System -> SubSystem to Console (/SUBSYSTEM:CONSOLE) But the problem still persists
Help me out of this.
It seems, that you misunderstand the term "module". There is no such C++ project in Visual Studio; C++ projects may be divided into three categories:
Programs - compilation produces an exe file, which may be executed;
Static libraries - compilation produces a lib file, which may be included in another project and are linked during the compilation;
Dynamic libraries - compilation produces a dll file, which may be attached to your program at run-time and provide additional functionality.
From your description, you want the projectB and projectC to be a static libraries, but instead you created them as executable files. Run the new project wizard again and choose "static library" instead of "Windows application".
You can read more about static libraries in the MSDN library.
If static libraries are too heavyweight for your application, you may simply include projectB and projectC files in your project (optionally take care of namespaces not to confuse the names of classes). It all depends on how much functionality you plan to implement in these "modules".
set Properties -> Linker -> System -> SubSystem to "Windows (/SUBSYSTEM:WINDOWS)"
What's happening possibly, what was happening with me, is that when you switch your properties of your project to .dll from .exe, if you switch from debug to release or from x86 to x64, each time you do that it's switching you back to .exe. Each configuration has it's own properties.
So, go to Properties > Configuration Type > .dll
If indeed you want to make a .dll.
I'm going to guess you're using Windows for creating this project, for me, if I usually use SDL I get this error, all you have to do is type in this #include <Windows.h> that should fix it, if not then I'm not to sure how to fix that.
say I have a sln which contains 10 projects(named proj1 to proj10), and proj1 is the default project which generate the EXE file.
My problem is: how to place the 'include' folder?
I mean if proj2 uses proj3(that is including its header file and linking its lib file), how to place the 'include' folder?
there are two approaches:
place all header files and lib files in a different root folder which is in the same level of the project
make every project self-close, and the other projects who want to use this project should take care of the include-path and link-path. Of cause we should give a rule to the layout of every project(e.x. every project MUST have a 'include' folder and 'lib' folder in the root folder)
any suggestion?
thanks
When it comes to Visual Studio, I don't like either of the two approaches you suggested, although mine is most closely related to your Option #2. The way I like to organise it is like this:
<SolutionRoot>
<Project1>
project1.vcxproj
someheader.h
somesource.cpp
<Project2>
<Project3>
<Project4>
<Project5>
application.sln
In case that's not obvious, that's a quasi-directory listing showing some project folders and the base solution file.
All new projects are just added to the solution using Visual Studio's default settings. Trying to go against this and making projects work like Linux projects (lib, include, src etc) just ends up causing you grief, so don't do it.
Now, I set my "additional includes" path on every project to $(SolutionDir). Then if I want to include something from Project1:
#include "Project1/someheader.h"
The advantage of this is you don't clutter up your 'additional includes', so it's easy to see at a glance what external includes a project has.
As for linking to lib files, why not take advantage of Visual Studio's project references feature. Honestly, your life will be easier. Simply hook it up so that Project2 references Project1, etc... Then you don't have to worry about libraries and linker paths. You only do that for toolkits that are outside your solution tree (eg distributions such as libpng or openssl).
Again, you free up that setting so it only shows linkages outside of the solution. The other advantage is that your build order is implicitly defined if you use references.
I would go with the 1st solution. it make the project settings simple. As the C++ projects we worked on, we always put the header files together.