Compile C++ with netbeans - c++

I'm currently making a small C++ program for my friends. I'm using Netbeans in school for Java and wanted to use Netbeans for C++ too (I want to use the same IDE for everything).
Now when I run my program in netbeans, it works perfectly in the IDE. But when I try to compile my program I can't seem to find the .exe file. I can only find the debug .exe file, which I can't run because I miss 3 .dll files (cygstdc++-6.dll, cygwin1.dll and cyggcc_s-seh-1.dll)
Am I doing something wrong? I can't seem to find the problem at this moment
thx for the help

If you want to have release .exe - you need to compile in Release mode instead of Debug
Regarding the issue with missing files:
My assumption is that Netbeans has a built-in compiler (which from your explanation appears to be one within cygwin environment). Having it built-in simply means that the IDE knows a path to all the sources (.dll) and header files
When you try to run the .exe out of the IDE - your executable cannot find these libraries (cygstdc++-6.dll, cygwin1.dll and cyggcc_s-seh-1.dll) because they're not set in the environment variables and are not visible from the executable's folder. (I expect, that the path to these .dlls is not hardcoded)

Related

Cross Compiling with Cmake. What should I expect from cross compiling

I also want the code I developed for Linux to work on Windows. I wrote simple Hello world code for this. I was able to create the .exe file with minGW using Cmake. When I run the .exe file directly on Windows, I got the error "libstdc++-6.dll not found" even though it exists on my computer. When I deleted the contents of the /build folder in Windows and built it with Cmake, the newly created .exe file worked. When I compile directly with minGW without using Cmake, the .exe worked without problems.
Is it a mistake to transfer the .exe file with its source codes to the Windows environment and expect it to work directly? I want to understand the logic of this concept properly.
If you use libraries that are not part of Windows itself, you will generally need to distribute the DLLs for those libraries in the same directory as the EXE in order for your EXE to work on another computer.
Alternatively, many cross-compilers support a -static argument that you can pass at link time in order to statically link these libraries into your executable. I favor that approach, but the licensing requirements for it are stricter.
(Make sure you follow the license terms for any software you redistribute that isn't your own, open source or otherwise.)

Missing libgcc_s_seh-1.dll starting the .exe on Windows

Intro
I have a CMake-based C++ project. Until now I build and ran the project via CLion. Everything worked fine until I tried to run the .exe-file directly (not via CLion).
Problem
When I navigate to the cmake build directory in order to start my program via the executable file, it fails with the following message in the popup: Cannot continue the code execution because libgcc_s so-1.dll was not found. Reinstalling the program may resolve the issue.
I have the following questions
If I interpret the error message correctly, then this dll is missing on my computer. So I ask myself, why does my program still work when I start it via the development environment (CLion), although the error message expressly states that the source code requires this dll?
Is it the fault of my application/source code that the error appears or rather the current state of my computer? If the former, how can I prevent this error from appearing for other users?
What is the best way to fix this error? It's obvious that I need to download this dll, but where is the best place to put it (which directory and environment variable to use on Window)?
Which source is trustworthy to download this dll? I don't want to download any malware under this dll-name.
Optional: What kind of library is that? What functionalities does it offer?
Additional information
I use CMake as my build tool, CLion as the IDE and MinGW as the compiler.
What I have did so far?
I made sure it still works through the IDE.
I found this dll does not exist in the MinGW installation folder.
I searched the web for more information. Unfortunately, there are only pages unknown to me that only offer the download of this dll. That doesn't satisfy me.
I found the cause of my problem: I had two MingGW installations on my machine. Once the installation that comes with CLion and a separate one. The latter did not have the required dll. However, CLion used its own installation, which in turn owns the DLL. So the solution was to remove the separate installation and include the path to the CLion installation's bin/ directory in the PATH environment variable.
This file is part of MinGW-w64 when using SEH as exception model (as opposed to Dwarf or SJLJ). You need to distribute the .dll files your .exe file(s) depend on in the same folder as the .exe file(s).
If you don't have that file, then you probably have been using libraries compiled with different versions of GCC/MinGW(-w64). I recommend building everything with the same compiler to ensure stable binaries.
Tools like Dependency Walker can help you figure out which .dll files your .exe file depends on.
Or use the command line tool copypedeps -r from https://github.com/brechtsanders/pedeps to copy the .exe files along with it's dependencies.

How do I inform the debugger of the location of run-time linked DLL files?

I have a C++ program that uses the freeglut library (and hence requires the freeglut.dll at run-time. I have added the folder C:\Program Files\Common Files\freeglut\bin to my PATH environment variable.
To confirm that the location is correct, when I compile my program (debug build) and run the resulting .exe file, it works fine (the freeglut.dll file is not in the same directory as the executable).
However, when I run the program directly from the VS2012 debugger, I get this message:
The program can't start because freeglut.dll is missing from your computer. Try reinstalling the program to fix this problem.
I know that one solution is to place the freeglut.dll file in the directory of the executable. This is what I've been doing so far, but I would much rather simply inform VS2012 (or my program) of where to find the dll file. Note that this post also seems loosely related, but it doesn't seem to contain an answer relevant to what I am trying to achieve (I just want the debugger to look in the same place for DLLs as any other program!).
How do I achieve this in VS2012? Icing on the question cake would be an explanation as to why the debugger doesn't just look in the PATH variable like any other program...
You can also set project based Environment:
Open project Properties
Go to Configuration Properites -> Debugging
Enter the path in Environment, eg:
PATH=$(PATH);C:\Program Files\Common Files\freeglut\bin
Restart Visual Studio after modifying your PATH variable.
What I did actually worked. I just didn't restart VS...

SDL.dll is missing from my computer - VS 2010

I'm trying to compile a SDL-program I've written, but when I do, this error shows up:
The program can't start because SDL.dll is missing from your computer.
Try reinstalling the program to fix this problem
I have no idea as to why. I have SDL.dll.
I have put it in the correct folder: C:\Windows\System32.
I have the correct PATHS to all the SDL headers and such as well.
VS says:
Build succeeded: 1
and THEN the error above pops up on screen.
Add it into your debug folder or whatever directory your program is currently located at.
SDL.dll has to either be in the same directory as your application, or in a directory that's in the PATH environment variable.
IfSDL.dll is 32-bit and you're running a 64-bit system you have to place the dll into /Windows/SysWOW64/ rather than /Windows/System32/, which is used for 64-bit dlls.
EDIT:
You probably shouldn't be deploying your DLLs by copying them into the System32 directory, unless they're common libraries that are used by several applications, and even then I would use discretion. For example, an application could update the DLL, which could break other applications that rely on an older version of the library.
Instead, copy the DLLs into the same directory that the executable is being built in. If you're building and executing with Visual Studio it will look for the DLL in the Project directory, where your source files are probably located.
Just place your SDL.dll in the same folder and your problem will be solved.
And to answer to your problem with the PATH, you can specify in visual studio where he will look for executables while debugging. Maybe this isn't set correctly and that's why VS can't find SDL.dll?

Using a DLL with unmanaged code in Visual Studio 2010?

I'm fairly new to C++ and an trying to figure out to use the TagLib library for a project I am working on. I'm working with unmanaged C++ in Visual Studio 2010 on Windows 7 64bit. I've never used an external library before so I'm very confused on how to go about this.
From this blog entry I got the libtaglib.a and taglib.dll files. I ran across this SO question on how to use TagLib, but it deals with QT Creator, not Visual Studio and I'm not knowledgeable enough about the subject to understand what is being said to translate it into what needs done for Visual Studio.
So, some questions:
Is it even possible to do this with unmanaged code?
What exactly is the function of a .a file?
Most importantly, how do I go about using the taglib.dll in my program??
I've been all over Google looking for a way to do this, but my major problem is that everything I run across is over my head. Please let me know if more info is required. Any help is very much appreciated! Thanks!
I seem to have gotten it working successfully. Here's a rough outline of what I did:
1.) I used CMake to generate the Visual Studio solution.
2.) I attempted to build the tag project in the VS solution, but it failed.
3.) I made the corrections to a few source files as outlined here: http://old.nabble.com/taglib-fails-to-compile-with-MS-VC%2B%2B-2010-td29185593.html
4.) I built the tag project again in release mode. This time it was successful.
5.) I copied the resulting dll, def, and lib files to the same directory as the source files for my project.
6.) I copied the header files from the taglib source to a subdirectory in my project (not sure if this entirely good practice)
7.) In my project settings, I set the subdirectory with the header files as an additional include directory.
8.) I added the dll, exp, and lib files to my project by just going to Add>Existing Item.
9.) I added some code from the taglib examples and built it. Everything worked so I think I got it.
One caveat I ran into, since the DLL was built in release mode, my project had to be run in release mode or it would crash. I'm guessing that if I replaced the DLL with one built in debug mode I could run my program in debug mode, but I have not tried this.
You cannot use libraries specific to GCC (you can tell because they have .a extensions) with Visual Studio. You will have to build the library from source in order to use it with MSVC. Once you have done that it's a simple matter of adding the .lib generated from the build process to your project and things should work out of the box. (Note that it's a .lib you need whether you're compiling for dynamic linking or not -- doesn't matter in msvc land)
EDIT -- after looking at TagLib itself --
In order to compile TagLib you'll need to get the CMake build system, and TagLib itself, and have CMake build you a visual studio solution. Using that solution you'll be able to build the .libs and .dlls you need. Note that because TagLib is a KDE library, you'll probably need to also build some QT bits in order for everything work work successfully. However, I don't have specific experience with the library so I'm not going to be all that helpful here.
Yo do not have to recompile the source (to create the .lib file) if you have the .dll file. With dumpbin /exports and lib (both came with Visual Studio) yo can create a lib that you can link with your application. In this link you can see a nice explanation: http://www.coderetard.com/2009/01/21/generate-a-lib-from-a-dll-with-visual-studio/
But as Billy Said, probably you would need other parts of QT to use this library.