In a Visual Studio 2010 solution, I have 2 projects:
Project A which is a dll project
Project B which is an executable project and depends on project A (configured through the solution project dependencies properties)
When I add new APIs in project A declared with __declspec(dllexport) specified and call them from project B.
If I simply "Build" the project B, it turns out that project A is built then project B but the linker does not find the new APIs and report them as unresolved external symbols.
Now if I "Rebuild" the project B, the solution is fully rebuilt and I do not have unresolved symbol linker errors.
Any idea what could cause the builder to not find the new symbols using a simple Build action and how to fix this?
Pretty hard to explain this with the info you provided. It clearly strongly suggests a build order problem, even though you documented that A gets built first.
You may have a problem with the parallel build feature available in VS. If it doesn't see any dependency between projects then it allows projects to build concurrently, taking advantage of your machine having multiple cpu cores. You can see A starting building but B starts building right away as well. Indicated with a numbered messages in the Output window, preceded with 1> and 2>.
If there actually is a dependency then it becomes a race. If B progresses to the link stage before A is done linking then it will certainly have trouble. But that is typically announced by it complaining it cannot find the import library for the DLL project. It finding an old version of A.lib that is missing some identifiers would be an unusual corner case. Things do however get interesting when it finds A.lib while it is being written. Which does explain what you observed.
Best thing to do is to ensure that VS knows there is a dependency without relying on it figuring it out by itself. It is not very good at figuring this out for C or C++ projects. Right-click your B project in the Solution explorer window and click "Project dependencies". Tick the A project. Now it will no longer build concurrently, B won't start building until A is done. Which is essentially what you did by hand to work around the problem.
If you still have trouble then you'll need to suspect other programs on your machine, the kind that mess with files. Anti-malware software is always on the top of the list of troublemakers like that. Avast is especially notorious for giving VS a hard time.
I have a question does it happens every time? It should not. Build command links, create binaries, find resources depending on the existing resource. No, if you change any resource like library, images form designs etc. Then you need to rebuild (clean+build).
To make a project build before another project build. You have to add dependency by this:
Right click to solution>properties.
Go to Project Dependencies > Select the project and tick the dependent project.
Finally right click to your project B select Set as StartUp Project.
This will force your project to build sequentially.
Related
I've downloaded VS2017 Community Edition and I'm working through "Programming in C" by Stephen G. Kochan.
I'd like to store all the examples in one project (possibly 1 project per chapter), however I've come across the error about multiple "main" files in one project. Before telling me I can't have multiple main's in a project, could you suggest the best way to organise these small C programs in VS2017.
I love the fact that I don't have to use a terminal compiler and would like to use VS2017 to work my way through the book.
Any suggestions?
A typical case of "assignments" in a course. In that case you can create one module (c file) for each assignment and call the current assignment from your main. Now you have all assignments in a single project, so you can easily look them up. Assignments completed you can comment-out.
I don't think you really want them all in one project. I think you want them all in one Solution, with each example in its own Project. That way you can switch between projects in the IDE and build/run/debug whichever one you are working on at the time.
Add a new project to your solution by right-clicking the solution in Solution Explorer and selecting Add->New Project from the menu.
Set the active project by right-clicking the project in Solution Explorer and choose "Set as startup project" from the menu.
This allows you to build each example on its own, or build all of them at once. Each project is self-contained and generates its own executable, and you can navigate around from one project to another inside the IDE.
You can compile and run your C files individually from command line.
This is not ideal when using an IDE.
Your other option is to use add_executable command in cmake
Adds an executable target called to be built from the source
files listed in the command invocation. The corresponds to the
logical target name and must be globally unique within a project. The
actual file name of the executable built is constructed based on
conventions of the native platform (such as .exe or just
).
I'm trying to create setup for my project. I added the new project with "Setup . When I add primary output to the project, I got the following warning.
"The following files may have dependencies that cannot be determined automatically. Please confirm that all dependencies have been added to the project C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\Ltocxu.ocx C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\LtocxVariantu.dll
Please guide me to solve this problem.
Thanks in advance..
This warning is a "general" warning and not one that may necessarily stop the software from working. It only means that since OCX and DLL files are older technology, the new setup project may not be able to detect the dependencies for these files. You may want to check the LeadTools documentation or find the dependencies manually and add them to the distribution as required.
Again, since this is a general warning for the tool (setup project) itself and not your project specifically, even if you add any missing dependencies.
In this particular case, the warning might be valid. The old LEAD Main OCX (Ltocxu.ocx) did require additional DLLs to work. Some of them are directly linked as dependencies like the kernel and display DLLs (LtKrnu.dll and Ltdisu.dll).
Others are dynamically loaded if needed, such as file format DLLs.
You should be able to find full details in the topic "Files to be Included with Your Application" in LEADTOOLS help files for your specific version of the toolkit.
I have a Visual Studio solution which I'm trying to build using the Incredibuild tool. Two of the projects in the solution work in tandem - the first project (we'll call it "Project A") builds an executable (foo.exe) which can parse a data file in the second ("Project B") to generate some header files.
Obviously there is a dependency on Project A defined in Project B. If I use Incredibuild's Rebuild Project option on Project B, it correctly builds Project A and foo.exe is successfully built. Project B has a custom build tool file which should cause foo.exe to be ran with a command-line argument to the file it's supposed to parse. However, trying to launch foo.exe in this way always returns an error:
CustomBuild:
Running Foo
'path to executable\foo.exe' is not recognized as an internal or
external command, operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
Interestingly, if I then use Incredibuild to build only Project B (i.e. using the Build Project option), everything is ok - it correctly picks foo.exe from the location it was built to on the previous, failed, build. This makes me think that the path, at least, must be ok.
Can anyone suggest why the executable cannot be ran as part of the rebuild? Is it a timing issue, e.g. Project B commences before foo.exe is known to the file system??
It all works under Visual Studio's regular (re)build. It's just the Incredibuild rebuild which fails. Note that I'm doing all of this through the Visual Studio IDE, not from a command line.
Edit: this is the freebie version of Incredibuild that I'm using (the one which comes with Visual Studio), so all of the build is on the local machine.
I contacted the Xoreax technical support about this in the end and they told me that this is a "rare but known issue that is related to one of our extra accelerating features".
Their first suggestion was writing an executable which simply sleeps "for a few milliseconds" and having that run as part of the custom build tool post-link. This did indeed solve the immediate problem, but the solution I'm building has numerous similar problems and adding this delay in everywhere quickly became tedious and didn't always work. It felt like a fudge anyhow.
So I asked if this behaviour can be toggled to off, and indeed it can. In Visual Studio the Incredibuild menu has an Agent Settings option, and from the invoked dialog's Visual Studio Builds|Advanced page it's a simple case of unchecking the Enhance throughput using out-of-order tasks spawning option.
Case closed.
There are options how to offload or intercept custom tools during your build process. Try to look onto "c:\program files (x86)\IncrediBuild\Samples"
I have mostly used kate, vim etc to code and just pure console and gdb (rarely) to test. I want to start using eclipse, mainly for ease of looking up stuff, and hopefully (while not super important,) run the GUI debugger.
However, I don't want eclipse to touch my real project folders (it should change the code, obviously, but don't want it to create any configuration folders etc). Is that possible? I was thinking to create a workspace on a different folder, and add sources from my project path. But this seem to be complicated without any experience with eclipse when handling Makefiles etc!
Anyone has done something similar? any guidelines?
Yes, this is fairly straightforward. Instead of creating a standard C Project that creates and manages makefiles for you, use the "Makefile Project with Existing Code" instead.
If you don't want the .cproject, .project, etc files intermixed, create the CDT project in an empty directory and use Linked Files and Folders to pull in what you do want in the project.
If you do try to do a Build within Eclipse it will do "make all", but if you don't have a Makefile you get this (same for clean):
make all
make: *** No rule to make target `all'. Stop.
What I have done is for projects that don't have a make equivalent (like CPython extension) is to write a trivial Makefile that delegates all and clean targets to my real tool.
Once you have the project created, you will need to configure it to get all the goodness of CDT. The CDT Indexer and Scanner needs to know about your compiler settings (includes and defines really). There are two ways of delivering that information:
Run a verbose build (i.e. with gcc command line arguments echoed) from within Eclipse (e.g. use trivial Makefile described above). CDT will parse that output and automatically pick up compiler options used.
There are a number of ways that CDT can learn about what your settings are, to configure how they are picked up, head to project properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. and adjust the sources in the Providers tab:
In the project properties, edit the C/C++ General -> Paths and Symbols properties. You may have to do this if CDT cannot determine all your settings in Step 1 too. This is a screenshot of some of those settings:
I have a Visual Studio 2012 solution with multiple projects, but I am only concerned with two at present. Project A is a static library written in C, and project B is an executable written in C. Project B depends on project A, and that is specified in the Project Dependencies settings.
The problem is that if I rebuild project B, I get error LNK1104: cannot open file 'projectA.lib'. However, if I rebuild project A first, and then build project B, there is no problem.
Oddly enough, the rebuild of project B does not actually create projectA.lib as I would expect, despite that I see this line in the Output window:
2> projectA.vcxproj -> C:\<build_location>\projectA.lib
I also see that line when I rebuild project A, and in that case it does actually get created. Why is the file not generated if I just rebuild project B, and how can I fix that?
EDIT:
I've discovered that this problem also exists for two other projects with a similar relationship. Let's call them project C (a static library) and project D (an executable). Both are written in Fortran and compiled with Intel Composer XE 2013. D depends on C. Again, rebuilding D does not create C as one would expect, but building C works fine. (Unlike A, it does not have to be rebuilt, just built.)
It is also worth noting that B also depends on C but that doesn't cause a problem. It's only when they have the same language that I see the problem.
The problem was that I had managed to put all four projects into the same directory. Apparently, certain parts of the build process use metafiles or temporary files that use compiler-specific names instead of project-specific names, and having multiple projects using the same compiler in one directory means that those files get reused and overwritten.
The solution to the problem is to move each project to its own directory. You can get away with keeping one C and one Fortran project together in one directory, but if you have to start making new directories like I did, you may as well make one for each project.