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.
Related
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.
I've read multiple posts with regards to this topic, but none of them have enabled me to build a statically linked exe.
In my release configuration (x64) I have the following:
Configuration Properties -> General : Use of MFC - Use MFC in a Static Library
Configuration Properties -> C/C++ -> Code Generation : Runtime Library - Multi-threaded (/MT)
Configuration Properties -> Linker -> Command Line : Additional Options - I have all the required Windows libs "kernel32.lib", etc. (as use of MFC removed them from the "All Options" window above)
Configuration Properties -> Manifest Tool -> Input and Output : Embed Manifest - No
Note that in Configuration Properties -> Linker -> Input there are 5 lib files that I'm using in my project, eg glfw3.lib and I'm using Full optimisation (/Ox).
After building the project and running the exe myself I receive errors "The code execution cannot proceed because glfw3.dll was not found..." etc.
Using dependencywalker I can see that it needs the dlls associated with the libs, which it of course cannot find.
Am I misunderstanding how to do this or is there something else that might be wrong?
(I'm using Visual Studio 2017)
Yes, it appears you have a slight misunderstanding.
If something is offered as a DLL, then it is meant to be used as a DLL. There may be some way to incorporate a DLL into an executable, but it would be a hack. That's not how things are supposed to work.
The lib file that you are linking against exists simply in order to provide you with functions that you can link against, and these do nothing but delegate to the corresponding functions in the dynamically loaded DLL. Without it you would have to locate each entrypoint of the DLL yourself, which would be perfectly doable, but a bit cumbersome.
So: you must either find a version of glfw3 which is packaged as a statically linkable library (I have no idea whether one exists) or live with the fact that your .exe will need to be shipped together with glfw3.dll.
I am having issues compiling a basic openGL program on VS 2012. I get a build error upon compiltation giving me:
1>LINK : fatal error LNK1104: cannot open file 'glew32.lib'
I followed the instructions given to me by the documentation for GLEW.
In your OpenGL project open Project -> Properties -> Configuration Properties -> Linker -> Input -> Additional Dependencies -> add glew32.lib.
Also you must include #include in your sources; For that add path to your glew folder: Project -> Properties -> Configuration Properies -> General -> VC++ Directories -> Include Directories and Library Directories;
C/C++ Tab -> General -> Additional Include Directories - Add lib folder there
I have also added the glew32.dll onto my Debug folder within my project folder along with the executable. So far I keep getting this error.
If you need any more further clarification of the steps I have done please don't hesitate to ask
In all honesty, there is no real benefit to using the DLL version of glew (short of reduced executable size, but this hardly matters on modern Windows PCs).
It is not like you can simply drop a new version of the DLL into your application and use extensions that you never used before. Likewise, bug fixes are so infrequent/unnecessary with a library that basically just parses the extension spec. files that using the DLL as a means of fixing extension loading bugs in shipped software is also not practical. Statically linking to glew (this means glew32s.lib) makes much more sense in the long run.
The static linking library is also more portable on Windows, it will work with MSVC and MinGW (whereas the DLL library only works with MSVC). Link against glew32s and put that in whatever directory you decided to use for additional library dependencies.
Here is a sample solution configuration for a project I wrote that uses glew. I have established a convention for this particular software where compile-time dependencies are stored under platform/<Subsystem>. Thus, I have glew32s.lib (32-bit) and glew64s.lib (64-bit) in ./Epsilon/platform/OpenGL/glew{32|64}s.lib
Steps to Use Classes form another project (Add header and solver linker errors)
To be able to add the header from another project, first go to "Properties > c++ > General > Additional Include Directories" and add the directory that contains the header. Now you will be able to add the header of the class from the other project, but running the project will still cause Linker Errors.
Add __declspec(dllexport) before the class you are using for the other project. This can be added in the header file of that class. This should be added right before the function or variable or class name. Now you will get a lib file. (if placed in wrong place, you can get this warning: https://msdn.microsoft.com/en-us/library/eehkcz60.aspx)
"Properties > Linker > Additional Library Directories". Specify the location of the lib file that is generated.
"Properties > Linker > Input > Additional Dependencies”: Add the name of the lib file.
This sounds like the library has been specified as a dependency, but the linker/additional search path(s) has not been set to include the directory where the library is located.
This may help.
It happened to me under this situation, I clean the solution and build it again, then many errors like LNK1104 occur.
After trying to restart IIS, I build solution successfully without LNK1104 errors. I do not know why, but restarting IIS takes much more time than normal, so I guess something is used by other IIS worker process.
Just give a shot to see if this magic happens on you.
This question is old and marked solved, but I had a similar problem symptoms with a completely different solution. So just in case anyone else stumbles in here:
It appeared that because I had 2 projects under one solution (a dll and an exe), the building order was mixed (from the output window):
1> Rebuilding project1..
2> Rebuilding project1..
1> file1.cpp
2> file1.cpp
and so on. By the message you copied, it appears you too have more than one project under one solution. One project was looking for the *.lib file that the other build hadn't created yet.
Solution:
Right click on "main" project -> Build Dependencies -> Project Dependencies.. -> Mark which project the main one depends on.
I'm porting a project over to Visual Studio and running into this problem. I have a project that I want to build and use as part of my solution, but it won't build itself.
When I build the solution, that project gives the error "No entry point".
The other main project that will rely on this library project then gives linker errors, since this won't build. What is the correct approach for this?
For reference, the code I'm trying to build is from here, and the library is imageLib.zip from there.
Go to the project properties page, and set "Configuration type" to "Static library" or "Dynamic library", rather than "Application". You might also need the /NOENTRY flag.
In Project Properties, Configuration -> General -> Configuration Type should be either Static library (.lib) or Dynamic Library (.dll).
probably, project that you are trying to port is static library, or DLL, both don't have a "classic" main function. Try to change Configuration type, or define entry point.
I have one solution with several projects. Say ProjectA is the one that will produce the exe file, and ProjectB simply produces a .lib file. I have checked that ProjectA depends on ProjectB, so that ProjectB will always compile before ProjectA.
When I compile ProjectB everything goes fine. But if I compile ProjectA I get linking errors saying that some method of B does not exist. I have checked, and it does exist.
¿What is going on?
Thanks for your help!
Project Properties, Linker, General: Set "Link Library Dependencies" to Yes.
I found there were several things I needed to check to fix the vexing link error:
"link.exe" exited with code 1104.
As per #Eric's answer, on the top level (Project A) : Project -> Linker -> General -> Link Library Dependencies : Yes
Select the parent / top level project, and in the Project Properties prop list, click Project Depdendencies and ensure Project A references Project B
Somewhat counter intuitively, on ProjectA ensure that you don't have an additional linker library dependency on ProjectB.lib. This seems to encourage to look VS to look for another library called ProjectB.lib, elsewhere.
You do not need to add the output directory of ProjectB to ProjectA's additional Link directories (default is $(SolutionDir)$(Platform)\$(Configuration)\).