I'm lost here and I have no clue how to proceed. This is not a question about how to make my program work, this is a question about how to stop wasting my time.
My programming environment is Visual Studio 2013 on windows, in C++.
I use 3 libraries extensively, namely: boost (using dynamic linking), OpenCV, and Qt.
During the development, I have configured VS to look at those 3 libraries by default for include and .lib. I have also added the 3 folders containing all the dlls to my PATH environment variable.
It works, but it is sometime painful, let me explain you when.
First hassle: Anytime I have a LNK error telling me I miss a function, it is usually on OpenCV since it has only one include file referencing all the functions. I have to look at OpenCV's source code to see what module this function belongs to and to know what I must link my program to.
Second Hassle: When comes the time to deploy my application, I have to ship it with all the relevant dlls. To know which one I need, I open dependency walker and try to forget nothing, I have then to test it on a different computer because 102% of the time I have missed a couple, and then I have to configure my Installer generator to include all those one by one.
Third Hassle: To ease a little bit the process of configuring a new development machine, I have recently switched to NuGet. It is great, I add boost with a couple of clicks to any project. But now my boost DLLs are everywhere, I have one folder per boost library, and since there are dozens of those I can't even add them all at once to my PATH now, so I have to move them manually to the appropriate folder, and that is really not what I want to do with my not-so-precious-but-who-are-you-to-judge time
I have looked around and couldn't find any good practice regarding this issue, maybe because they are too obvious, or too specific to a particular setup.
How do you do? How would you do if you were me?
We put all our external dependencies in version control along with the code. This ensures that all code can build "out of the box" on any of our development machines and also ensures that for any given version of the code, we know exactly which dependencies is has.
The best way to check for missing dependencies is how have a good automated test suite, if you've got comprehensive converge then if your tests pass you must have deployed the required libraries.
In terms of linking to the appropriate libraries, unfortunately, that just sounds like an issue with the structure of OpenCV (I'm not familiar with OpenCV). I tend to use dumpbin under Windows and nm under Linux to easily grep for symbols when I get link errors with an unfamiliar library.
Related
I'm a unix backend dev that has a small roll in maintaining a visual studio project. The vast majority of my code runs on Linux, with a small Windows footprint. There is a proprietary project-specific rule in play here that states all system dependencies must be dynamically linked, but all other dependencies not already installed on the systems, which I thankfully don't control, must be static. In other words, I can use boost, poco, mysql++, zeromq, etc, but those have to be linked statically. I also can't create my own DLLs. My Linux brain is guessing that rule is my Windows problem.
I have a large static library as part of the projects with lots of common code linked into other programs. That static library is compiled /MD, which appears to be what I have to do on Windows to dynamically link system libraries. However, I need that library linked into other programs statically. When I add a reference to the library in VS 2017 to other projects, nothing happens and the symbols aren't resolved and I get lots of link errors. To fix that, I hard-coded my library into the various other projects via Linker->Input->Additional Dependencies and that "works" after a fashion, the code links and runs but VS doesn't resolve the static library dependency. While I can go forward with this solution, it's hardly ideal. Rebuilding the solution always results in failure (or links in old code into a new build) because the big static library always takes the longest and none of the other projects know to wait for that build to complete. The workaround is to build the static library first, then build the entire project.
Does anyone better versed in Visual Studio know the best way to proceed?
Can someone help me understand why this got down-voted? This isn't a troll and I'm hardly a student trying to get someone to do my homework, it's a real problem I'm trying to figure out in a professional setting. I thought that was the whole point to stackoverflow?
So this was something simple. When I went to add the reference I didn't actually click on the check box. Robert Andrzejuk's second comment helped, I had read that before but didn't notice the little check box the first time.
On the add a reference page (right click project in solution browser, Add->References...), the check box next to the item has to be selected.
Add reference widget
I have created a simple application in Qt5 but, when run that application in for example windows 7, tells me the dll file something is missing, and another dll and another dll.
Now I want a package that contain all dll files that any Qt application needed.
Or, What's the Important dll files that needed to work any Qt application ?
Or, What's the Important dll files that needed to work any Qt application ?
In general, the Qt modules that you are using. If you use QtSql, you need to have the corresponding dll, but it goes the same way for any module. As for a simple core application, you would need to have the QtCore dll, respectively. I could continue the enumeration, but I believe you see the pattern how it goes.
Going even a bit further, you would need to specify your dependencies in the LIBS variable if you happen to use qmake. That is also a place where you would already need to be aware of your direct dependencies.
It would be usually the single library name, but in complex cases, you can always read the documentation of the project. The main point is the fact that you need to get aware of this without debugging. The latter would be more like an after-thought.
There are no "hidden dependencies". Since you are coding the project, you know the dependencies that you use. You will need to ship them.
There are some odd and rare cases when issues come that you would not be aware of, like missing dll for a different machine having a distinct VS/MSVC setup. In that case, it is better not to ship all the dlls for each possible end machine, but the end machine is supposed to install redistributable packages.
In rare cases when the above does not suffice, you can check the error message. If that is still unclear, you can use introspection tools for debugging the issue, like dependency walker.
Disclaimer: this answer goes as broad as the question is.
The situation is the following: I have the source code of one programm (lets call it programA) (written in C and C++), as well as the CMakeLists.txt and CTestConfig.cmake files. I already installed programA using CMake's graphical user interface and, as it is obvious, it worked. It created the .exe file (I'm working on Windows 7 OS).
The problem is that, right now, I've been asked to edit the program (and so, I must be able to edit the code and degugging it as changes are made). I also need to compile it but not in .exe anymore but in .dll so I can add it to a website we have.
I've read in forums that CMake can compile programA into a .dll if I need to, but as I would need to make some changes I consider that CMake debugging is not as useful and easy as using entirely VS. From the little I know from CMake language, the CMakeLists.txt is mainly used to check the OS of the user as well as adding some libraries in case they are not found.
I have to admit I have no idea in programming CMake directives, as I have been working with ASP.NET, C, C++ and C# mostly. Then, my idea is to try to work only in visual studio 2010 instead of using cmake as well, so once I have the program 'adapted' to VS and can be compiled just using VS, I'm ready to start my job. So the question I have is how can I perform the same task CMake did just using Visual Studio (Is there any way of implementing CMake directives in VS?), can VS compile by receiving as an argument something similar to that CMake.txt file (though it needs to be translated into another language)?
To skip the use of CMake I tried to copy the source code into a new project in VS. However as it does not use the CMake directives when compiling, it gives several errors, most of them related to the fact that some headers.h can't be found (cause they might be in a subfolder). And there are so many subfolders to add the paths to the predefined directories of search that it would take ages.
I'm sorry I can't be more precise in my explanation. I'm good at programming little projects on my own, but it's the first time I have to work on other's programm. Please don't hesitate to ask if anything was not properly understood
I would appreciate a lot any suggestion / advice /guidance you can give.
To make a dll, use add_library command and the SHARED keyword
add_library(mylib SHARED ${files})
this is easy with CMake, don't go back in visual that will be harder at the end
The Good News
Fortunately, cmake can generate VS Projects automaticaly for you (this tutorial s specific for OpenTissue, but Steps 1 to 3 should be the same for you).
The [not so] Bad News
Depending on the complexity of the project, VS Projects automaticaly generated by cmake can get pretty nasty, to the point of illegibility. It will, for example, hard link any library dependencies using the specific paths of your machine, so the project will most certainly not be portable across setups. In any case, that's the intended bahavior, because the primary idea of supporting this generator is simply making it work, thus allowing users to easily compile projects using MSVC, so there's not much you can do here. Nonetheless, it should work in your machine and will certainly be a great starting point for you, just create a project yourself from scratch copying the relevant parts out of the automatic generated version.
I have written and tested a library in C++. The code even works in my Android application if I add the source files directly. While I do have experience compiling static and dynamic libraries for common operating systems, I have zero experience compiling for a mobile system like this. I've done some research, and I'm still a bit lost as to exactly how to approach this. For example, I am unsure of whether to build a makefile for use with ndk-build or to just invoke one of the Android's compilers directly.
I did see this question, but it does not quite match my situation. I just want to run build and have it spit out libfoo.a (I'd like to produce libfoo.so as well, but libfoo.a is of greater interest to me right now.) The example in that question's winning answer implied that it would build the library as one step/module for building the final application. I tried doing it that way just to see, but I had no luck.
Can anyone please guide me in this endeavor?
CLARIFICATION -- I do not want to build the library and immediately pipe it into an application. I want a .a or .so file that I can link against in multiple future Android applications.
Create a dummy java file with empty code and make sure there is a android_main function in your C++ code. Build using ndk-build. the resulting apk will make your library an application.
See the samples from the android-ndk-r5/samples directory, see the sample native-bitmap to get some idea.
If I understand it correctly that a shared library is not acceptable and you want to be static (but why is that so important?), probably the easiest way to do so is to simply supply source code that can be added to a project.
Ultimately there is nothing special about the ndk build system other than it knowing the right commands to issue to build the necessary files for the assortment of curent android architectures. If you really want to do something different, you can log the operation of the android build system in creating a shared library, and then write your own Makefile that performs the analogous steps to create a static library. HOWEVER, you will have to update your Makefile any time the underlying assumptions or target collections change in a new android version.
I guess everyone has run into missing dll's issues from time to time. What I am trying to get is the 'recommended' method to find and install the dll's. Finding out which dll's are missing is easy enough using depends.exe.
Don't use depends.exe anymore, it hasn't kept up with developments in the Windows core and deployment strategies like the side-by-side cache. Trying to fix the warnings it gives will actually mess up your machine pretty badly. Only use it for hints if a program actually fails to start.
99% of the missing dll errors that I tend to come across are missing C++ runtime libraries (eg =MSVC*.dll=) or the .Net framework, where the developer has built with dynamic linking to the C++ runtimes but hasn't created an installer with the required merge modules, or they have built a debug version which links against the debug runtime libraries which you are not permitted to redistribute.
In the vast majority of these cases, simply installing the correct Visual Studio 2005/2008 C++ runtimes (eg see here) or .Net framework will fix the problem.
That depends greatly on which DLLs are missing and why they are missing, I don't know that there is a one-size-fits-all answer.
My advice would be to use depends to find which DLLs are missing, try to find out where those DLLs were supposed to be installed (and what application was supposed to install them), and then try to reinstall that application or find out what happened to screw up the dlls.
Another thing to check is for 32bit/64bit mismatches, that can make it seem like DLLs are missing sometimes, especially on 64bit platforms.
Or if you are using .NET, you can have trouble with assembly versions and the GAC sometimes.
You can also check the PATH environment variable, I would advise against blindly adding to your PATH to get it to find DLLs you want, that can cause all sorts of other weird problems.
Sometimes you have to hack around with the PATH or copy files to get things to work, but it is usually better if you can figure out what went wrong in the first place and fix it.
Get the DLL from its publisher's website, if possible, and then follow the publisher instructions to install. Don't forget to respect licensing rules!