Can VS2010 link EVERYTHING into exe file that is needed? Or should i put MS VS2010 files into installation package? I don't want user to think about downloading and installing something.
Having tried to use static linkage for this reason in a large MFC project, using VS2010, I find that I still need to run the VS2010 SP1 redist package. The software works to a large extent without it, but users see a fair number of additional random bugs that seem to miraculously disappear once the redist is installed. I'm guessing it updates other windows components that the run-times are dependant on, but it is only a guess. My advice is to include it with your installation.
Related
Ther are many articles about how to install spread library on Linux(1. download source & unzip it 2.run ./config 3. make 4. make install) but seems no article about how to install spread on Windows......
I had downloaded spread-bin-4.4.0-Windows8_x64 from official site(my environemnt is win10), but there is no .bat or .exe file found under the unzipped folder. Does anyone know how to install spread library on Windows?
In linux, there is a standard way of installing libraries that all the software on your machine is supposed to use. In part this works because all that software is chosen in such a way that the same versions of libraries will satisfy everyone, that's what makes up a linux distribution to some extent.
In windows, the model of development is totally different. Any third party software, not from microsoft, is something the customer paid for and microsoft never signs off on it or anything. Third party stuff generally is supposed to provide its own libraries since you have no idea what other third party stuff is present. There's not much point in globally installing things since most programs won't use what you globally install anyways.
So, if you have a library on windows, you should install in whatever way the program that you intend to use it with will find it. If you are intending to install it for use with a project you are developing, that is a different question, and ultimately one about your build system or IDE.
In modern days there are things like NuGet which allow you to do things in a more linuxy way on windows. But that's quite recent and not that much software from typical user's perspective gets its dependencies that way.
After further study, I found a Visual Studio solution file:spread.sln under \win32 folder! So in conclusion, to install Spread libarary on Windows:
1. get source codes from http://www.spread.org/download.html
2. unzip
3. open solution file under \win32 folder with Visual Studio
(Please note that "do not" use relatively new version of VS since this solution is built with older VS(like VS 2010) otherwise unexpected errors occurred)
4. build solution
There you go! You can build your project with Spread library now!
P.S. This spread.sln is a Win32 solution. I'm just wonder is there a Win64 version solution file......
So I have been programming in console C++ for a while, but I finally decided to try graphical applications using OpenGL. It took me a while to learn that GLUT and other libraries are obsolete, so I began installing and preparing GLEW and FreeGLUT. I managed to get to the point were my includes are working; however, now I'm running into this problem:
Visual Studio is telling me that I don't have glew32.dll when it is clearly sitting in the system32 folder. Is this not the default folder for these libraries?
In addition, every time I run my program (and hence get this error) the visual studio process continues running in the background, even after the program is closed. It refuses to be ended and it causes another problem: whenever I reenter Visual Studio I get a message saying that the default storage location is currently in use by another instance of visual studio (the one running in the background.) As a result, to continue working I have to restart my computer every time.
Does anyone have any clue what could be wrong with this and how I could get things up and running? This is my first time installing libraries, but I haven't touched random things in the system folder (at least not intentionally) and I've been careful to clean up behind myself when I've done something I shouldn't have.
Other info:
Visual Studio 2012
Latest stable releases of freeGLUT and GLEW
Windows 8.1 64bit
There are a few things worth mentioning here:
You really should not even bother with using the dynamic linking version of glew (glew32.lib). Just link against the static linking library (glew32s.lib) and forget that the DLL version ever existed.
The DLL version is more trouble than it is worth, especially since it will not work with other compilers (e.g. g++) on Microsoft Windows.
For goodness' sake, do not install glew32.dll to System32!
Never, ever, put any user DLLs there. This is the primary cause of "DLL hell." What you should do is distribute them along with your application instead (e.g. in your .exe's working directory) or if the software has a run-time redistributable installation program (glew does not) ship that with it.
I am willing to bet good money you are running a 64-bit version of Microsoft Windows.
You are compiling a 32-bit application, and it will run in Microsoft Windows' 32-bit compatibility layer known as Windows on Windows. All 32-bit DLLs will be sourced from a separate location SysWow64 when running in the compatibility layer.
This can be confusing, as you would think that System32 means 32-bit... but for historical reasons System32 actually contains the DLLs for the native version of Windows (32-bit on Win32 and 64-bit on x64).
Nevertheless, do not install glew32.dll to SysWoW64 either :)
Since you mentioned in comments that you do not understand what "linking against glew32s.lib" means, I will tell you simply that this line in your header file is causing the linker to use the DLL version of glew:
#pragma comment (lib, "glew32.lib")
This is an ugly hack for the Microsoft Visual C++ compiler that tells the linker to add this as a dependency. It is not understood by other compilers (e.g. g++), but if your software is always going to be compiled with Visual Studio you can continue to use it.
To change your software to use the static (non-DLL) version of glew, simply replace that line with this:
#pragma comment (lib, "glew32s.lib")
Now you do not need to distribute a DLL along with your program and this whole problem effectively disappears.
Ever since I picked up SDL (which was not too long ago), I have used Code::Blocks with MinGW to develop... on Windows. Setting it up for SDL 1.2 was easy and quick.
Now I want to start with OpenGL 3.2, and since I already know SDL, I thought using it for OpenGL would be logical. So I downloaded SDL 2.0, which supports OpenGL 3.x, and tried to build the libraries.
I tried to make install with Cygwin, but it did not configure because I am on Windows. To get the .lib and .dll files, I followed the VisualC instructions and was able to generate them.
But I was pretty sure I wouldn't be able to use the *.lib files with MinGW. I couldn't.
So I tried to use reimp to convert the *.lib files to *.a. It did not work, all libraries were found to be "corrupt". Even glew32.lib which I downloaded and did not build myself. I am quite lost.
Can I even get it to work with MinGW, or do I have to switch to VisualStudio?
(I don't even know if VC++ 2010 Express Edition will be usable. The only reason I was able to build the VisualC libraries is because I used the Visual Studio Pro Trial. VC++ 2010 was not letting me do so earlier.)
Update:
I used MSYS to build the *.a and *.dll.a for both SDL 2.0 and GLEW. My project was linked properly and built without any problems. But, I am unable to run it.
I get the error "The application was unable to start correctly (0xc00007b)".
I know this problem is due to incorrect *.dll files. I have linked all the *.dll.a files I built, and I don't know why this problem is occurring.
What am I doing wrong?
(Here is the pastebin of the test program I wrote, but I doubt that the present problem is with the code.)
Update v2:
I solved it. I just put the *.dll files into the System32 folder, as well as the SysWOW64 folder.
Then, I just had to debug my code. Currently, you can't simply call SDL_Init(SDL_INIT_EVERYTHING) because there is no haptic support.
Now that I've got my stuff working, I'll get to developing. Thanks for your help.
You might want to try installing MSYS, which will provide you with a bash shell and the utilities for building a library on Windows.
Here's my configuration:
Computer A - Windows 7, MS Visual Studio 2005 patched for Win7 compatibility (8.0.50727.867)
Computer B - Windows XP SP2, MS Visual Studio 2005 installed (8.0.50727.42)
My project has some external dependencies (prebuilt DLLs - either build on A or downloaded from the Internet), a couple of DLLs built from sources and one executable. I am mostly developing on A and all is fine there. At some point I try to build my project on computer B, copying the prebuilt DLLs to the output folder. Everything builds fine, but trying to start my application I get
The application failed to initialize properly (0xc0150002)....
The event log contains two of those:
Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system.
plus the slightly more amusing
Generate Activation Context failed for
some.dll. Reference error message: The
operation completed successfully.
At this point I'm trying my Google-Fu, but in vain - virtually all hits are about running binaries on machines without Visual Studio installed. In my case, however, the executables fail to run on the computer they are built.
Next step was to try dependency walker and it baffled me even more - my DLLs built from sources on the same box cannot find MSVCR80.DLL and MSVCP80.DLL, however the executable seems to be alright in respect to those two DLLs i.e. when I open the executable with dependency walker it shows that the MSVC?80.DLLs can be found, but when I open one of my DLLs it says they cannot. That's where I am completely out of ideas what to do so I'm asking you, dear stackoverflow :)
I admit I'm a bit blurry on the whole side-by-side thing, so general reading on the topic will also be appreciated.
Your question has the answer to your problem: Computer A has VC runtime of version 8.0.50727.867, and Computer B has only version 8.0.50727.42.
You built your libraries on Computer A, and they depend on version 867 of VC runtime. (This can be found in manifest embedded in the libraries.) When you copy them to Computer B, these libraries still require version 867 of the runtime but you have only version 42.
To resolve the VC runtime assembly dependencies, you have to install VC runtime redistributables of version 867 on Computer B. However, I'd advise you to update Visual Studio on Computer B so that you have the same version on both computers. And even better, install Visual Studio 2005 SP1 on both computers and then install this security update to SP1. After installing the latter, your libraries will depend on version 8.0.50727.4053.
it's possible the problem is related with different versions of CRT runtime installed on both machines. is it possible to build all your modules to use statically linked CRT runtime to verify this?
first I'd check that prebuilt dlls by preparing dummy project to load them
I recently had the same type of error when building projects on one machine and then moving them to another machine. The biggest culprit here is likely a debug configuration for one of the binary components. That is, MSVC has the fairly rigid requirement of all DLLs/EXEs being built with the same runtime library, debug or release, otherwise they will not work together.
When I had this happen they also tend to compile just fine, but when you attempt to run them you get that extremely cryptic error message.
You need to ensure that every module you build together uses the same configuration, thus debug or release through the entire build chain. This error also likely comes up with mismatches in other libraries, so make sure your MSVC is the exact same version on the machines where you are building.
I have installed cygwin. But when I try to compile a c++ file it gives the following error:
/usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1plus.exe: error while loading shared libraries: cygmpfr-1.dll: cannot open shared object file: No such file or directory
I checked in the lib folder there is no library with the name cygmpfr-1.dll. So is it that I have to put that dll in the lib folder. I have tried to search for the dll but could not find this dll so that i can download. I am just a beginner in C++. I have tried to setup cygwin support in netbeans as well, but there also if I try to run the sample files given, it throws the above error.
Can anybody give me a clue?
You need to install the gcc4-g++ package via http://cygwin.com/setup.exe
You only have gcc4 installed.
This will also install your missing dependencies.
If you're a beginner in C/C++, and you're running Windows, then why not take the simple route and get Visual-C++ Express, a free IDE from Microsoft for Windows.
It provides a GUI IDE (Integrated Development Environment), but if you prefer a text editor and command-line tools (compilers, debuggers, etc) those are available to you also, if you install Visual-C++ Express.
There are also tutorials and lessons to get you started.
On the other hand, if you really wanna focus on C++ on Linux, then you should probably uninstall Windows 7 right now.
I have had similar problems and I am no beginner. Try using the cygwin installer, and searching it for all versions of gmp. There generally are 32bit and 64 bit versions. Check everything you see and update your installation. Hope this helps. Some of these dll's you can find on the internet, but not the one you are looking for.