I recently started learning C++, coming primarily from Java. I know the basics now, and I want to test out some graphics. Obviously, C++ doesn't have the built in graphics API that Java does, so I'm trying my hand at using GLFW. Unfortunately, I can't even get it to initialize with glfwInit(). Here's my code (it logs "Could not initialize GLFW" to the console):
#include <GLFW\glfw3.h>
#include <iostream>
int main() {
if (!glfwInit()) {
std::cout << "Could not initialize GLFW" << std::endl;
}
else {
std::cout << "GLFW initialized!" << std::endl;
glfwTerminate();
}
std::cin.get();
return 0;
}
I've seen lots of similar test code before, so I'm assuming that the code is the issue. I'm also not getting any linking errors, so I think I did that properly. However, this is essentially the first time I've used a third party library with C++, so I could be making a simple mistake.
I'm using Visual Studio Community 2015, but since GLFW doesn't have any pre-built binaries for that yet, I had to build them myself with CMake. (Since I've never done that before, I repeated this whole process in Visual Studio Community 2013 with the pre-built binaries, and I got the same result.) I added my 'lib' and 'include' folders in the appropriate places in Configuration Properties -> VC++ Directories, and I added the 'glfw3.lib' and 'opengl32.lib' files in Linker -> Input -> Additional Dependencies.
I've found an abundance of posts where people have linking errors (which I don't have anymore) or can't get GLFW working even when initialization succeeds. However, I haven't been able to find anyone else with a problem quite like mine, nor do I know where to start in terms of debugging. Any help is greatly appreciated.
Okay, so apparently this was a bug in GLFW. I added an error callback and it returned "No monitors found." I found this discussion of a similar issue on the GLFW github page, and the owner added a fix recently that hasn't made its way into any official release. I downloaded the master branch, built it as I had before, replaced the libs and header files, and now everything works properly.
Related
The problem
I'm trying to build a project in Visual Studio 2015 on Win10 that makes use of libssh, but I'm having no luck getting it to work. I feel like I'm losing my mind here. I'm either completely blanking out or missing something incredibly obvious.
I've tried using the installer libssh-0.7.2-msvc.exe from the files section at https://red.libssh.org/projects/libssh/files. I then linked it to a test C++ project in VS2015. Using the sample code I'm able to compile it:
#include <iostream>
#define LIBSSH_STATIC
#include <libssh/libssh.h>
int main() {
std::cout << "Starting libssh test" << std::endl;
ssh_session my_ssh_session = ssh_new();
if (my_ssh_session == NULL) {
std::cout << "Failed to initialize" << std::endl;
}
ssh_free(my_ssh_session);
return 0;
}
(Note: I've tried both #define LIBSSH_STATIC and #define LIBSSH_STATIC 1 based on posts I've seen from my initial search for answers. I've even tried adding it to the preprocessor definitions in project properties.)
I can only compile it if my project is set to 32-bit, but I can't run the resulting executable. Doing so results in an error: "The code execution cannot proceed because ssh.dll was not found. Reinstalling the program may fix this problem." I'm statically linking ssh.lib, though, so I'm not sure why I'm even getting that error.
So I tried compiling libssh myself as 64-bit. It took some more tinkering than I expected (I had some issues with zlib, which eventually I just omitted since it's optional). I can compile my project as a 64-bit executable successfully, but once again, I can't actually run it. I get the same error about ssh.dll being missing.
For the sake of trying it, I removed the LIBSSH_STATIC define and tried to link just to the DLL. Copying the ssh.dll from the libssh distribution into my program folder and trying to run it, I get the error: "The application was unable to start correctly (0xc000007b). Click OK to close the application."
I'm not sure what I'm missing here, but I'm sure it's dumb and I'm overthinking it.
Project settings (all configurations, all platforms)
libssh is installed to G:\Libraries\libssh_0.7.2 on my machine.
Configuration Properties > VC++ Directories > Include Directories
G:\Libraries\libssh_0.7.2\include;$(IncludePath)
Configuration Properties > VC++ Directories > Library Directories
G:\Libraries\libssh_0.7.2\lib;$(LibraryPath)
Configuration Properties > Linker > Input > Additional Dependencies
ssh.lib;%(AdditionalDependencies)
libssh path summary
libssh_0.7.2
bin
ssh.dll
include
libssh
callbacks.h
legacy.h
libssh.h
libsshpp.hpp
server.h
sftp.h
ssh2.h
lib
ssh.lib
Install vkpkg
⊞ Win+X and open the powershell
Input vckpg install libssh:x64-windows
Integrate into Visual Studio: vcpkg integrate install
Then you can include <libssh.h> in Visual Studio.
I recently changed from Microsoft Visual Studio Community 2015 (which worked fine) to the 2017 version, and at first, it was working fine. I save my projects in C:/_Dev/C++/My projects/. However, after using 2017 for less than 3 hours, I now get this message whenever I try to run a project:
"This project is out of date:
[insert file name]-Debug Win32"
Then I have the option to build it or not, and building does still work, but I don't like that something is going slightly wrong.
Note that since I got this error, I went back to my first C++ program to see if it now displays the message too, which it does. The code is as follows:
#include <iostream>
using namespace std;
void main()
{
cout << "Hello World!";
system("pause");
}
...So I'm fairly confident it's not my code causing the issue. It's been a couple of days since I started getting the error, and I've tried re-installing VSC 2017, deleting the *tlog files, cleaning, and rebuilding the project. I have not moved the project to a new file directory since its creation.
Does anyone know if this will turn into a big problem, or is it just something I have to put up with? If anyone knows more, I'd appreciate the advice.
This is not a new question but the solutions haven't worked for me. I want to read dicom files using C++. I have 32-bit Windows PC with VS 2013 community edition.
This post and other answers therein suggested using DCMTK. I installed DCMTK (using CMake followed by VS) and configured it for use with VS using guidelines and links provided in this post. Then I wrote a simple test program and tried to compile it:
#include "stdafx.h"
#include "dcmtk\dcmdata\dctk.h"
#include "dcmtk\config\osconfig.h"
#include "dcmtk\dcmimgle\dcmimage.h"
#include <iostream>
using namespace std;
int main()
{
DicomImage *image = new DicomImage("test.dcm");
if (image != NULL)
{
if (image->getStatus() == EIS_Normal)
{
if (image->isMonochrome())
{
image->setMinMaxWindow();
Uint8 *pixelData = (Uint8 *)(image->getOutputData(8 /* bits */));
if (pixelData != NULL)
{
/* do something useful with the pixel data */
}
}
}
else
cerr << "Error: cannot load DICOM image (" << DicomImage::getString(image->getStatus()) << ")" << endl;
}
delete image;
return 0;
}
Upon compilation, it gives the following error:
dcmdata.lib(dcuid.obj) : error LNK2019: unresolved external symbol _Netbios#4 referenced in function "unsigned char * __cdecl getMACAddress(unsigned char * const)" (?getMACAddress##YAPAEQAE#Z)
This error seems to be common but none of the following solutions work for me:
FAQ#27 and another post of DCMTK forum: It suggests using particular order of lib files to be included. My order of including files is as follows (I tried the reverse order as well but it didn't work):
All of this doesn't work. In fact, I'm not sure which lib files are supposed to be included? How to decide that?
I've also included "C:\Program Files\DCMTK\lib" under additional library directories and "C:\Program Files\DCMTK\include" under additional include directories in project properties.
Another similar question at stackoverflow has not been answered. Comments suggest to re-run CMake by disabling DCMTK_OVERWRITE_WIN32_COMPILER_FLAGS. I didn't do it because the DCMTK help page says don't disable this unless you really know what you're doing.
Can someone please guide?
The NetBios function resides in NETAPI32.LIB, so you can try moving NetAPI32.lib (which is in your list) to the top of that list.
Not sure which version of the DCMTK you use, but for the current development snapshot you need the following standard libraries (on Windows): "ws2_32 netapi32 wsock32". This information can be found in DCMTK's CMake files. By the way, you don't seem to use CMake for your project, right?
I think you misspelled dcmsign.lib as dcmsig.lib.
If changing that doesn't fix it, I would suggest the following order based on the support page that you linked to:
NetAPI32.lib
WSock32.lib
ofstd.lib
oflog.lib
dcmdata.lib
dcmsign.lib
dcmnet.lib
dcmsr.lib
dcmqrdb.lib
dcmtls.lib
dcmwlm.lib
dcmimgle.lib
dcmpstat.lib
dcmjpls.lib
dcmjpeg.lib
dcmimage.lib
ijg16.lib
ijg12.lib
ijg8.lib
I think that in this list, each library has to come after all the libraries that it depends on.
check your .lib and vs platform if the same ,such lib for x64, then your vs platform must be x64.
I had the same error. You can go to project properties-> linker -> input -> Additional Dependencies-> Edit -> add these two libraries-( netapi32.lib,wsock32.lib) before all other libraries . This solved the error for me .
So finally I’m not able to help myself out by researching anymore. Hopefully you can help me.
I recently decided to learn C++ in the context of my bachelor-thesis: My first aim is to read the pixel-values of a tiff-image with the libtiff-library. Yet, every call of a function of the library seems to break parts of my program.
Here’s the simple “HelloWorld”-Program, it works as it should:
#include "tiffio.h"
#include <iostream>
using namespace std;
int main() {
cout << "Hello" << endl;
// TIFF* tif = TIFFOpen("path to .tif", "r");
return 0;
}
When I uncomment the second line in main(), the code still does compile without errors (except the warning that ‘tif’ isn’t used) and I can start the program as usual. Yet nothing gets printed into the console anymore. Not “Hello” nor any errors.
Any suggestions where the error could be? The code should be alright, I guess I messed something up during the setup of the library or so. Here’s what I did:
I managed to set up eclipse (Mars, 32bit) for C++ and MinGW (32bit) on my 64bit Win7, then downloaded libtiff 4.0.4 and built it following this instruction.
I created a new C++-project with the mentioned code and did the following adjustments in the project-properties:
Project->Properties->C/C++ General->Paths and Symbols->Library
Paths-> Added “D:/… /tiff-4.0.4/libtiff/.libs”
Project->Properties->C/C++ Build->MinGW C++
Linker->Miscellaneous->Set Linkerflags to “-static-libgcc
-static-libstdc++”
Project->Properties->C/C++ Build->MinGW C++ Linker->Libraries-> Set
(-L) to “D:/… /tiff-4.0.4/libtiff/.libs” and (-l) to “libtiff”
I know the .tif is a valid file as I implemented parts of my program in C#, using the LibTiff.NET library by BitMiracle.
Thank you in advance!
Edit 1: The same error occures, even if TIFF* tif = TIFFOpen("path to .tif", "r"); is never called but written down in a dead part of the code. Debugging does not work either, the program seems to be terminated (exit value 0) before a single line is executed, without any error-reports.
I had the same issue and managed to get rid of it.
I set up eclipse (Mars) for C++ and MinGW on my 64bit Win7, then downloaded libtiff 4.0.4 and built it following this instruction.
After the build, I got two directories containing files:
include
tiff.h
tiffconf.h
tiffio.h
tiffio.hxx
tiffvers.h
lib
libtiff.a
libtiff.dll.a
libtiff.la
libtiffxx.a
libtiffxx.dll.a
libtiffxx.la
I also linked all include files and only the libtiff.a to my project and that solved it, ie, the other lines are now executed.
I hope, I helped with this post.
Yesterday I decided to download, install, and attempt to use Allegro 5. I also downloaded Code::Blocks 12.11 w/ the MinGW compiler. I set up everything and installed everything correctly (or so I thought) and tried to run a sample code to see if it would work:
#include <stdio.h>
#include <allegro5/allegro.h>
int main(int argc, char **argv){
ALLEGRO_DISPLAY *display = NULL;
if(!al_init()) {
fprintf(stderr, "failed to initialize allegro!\n");
return -1;
}
display = al_create_display(640, 480);
if(!display) {
fprintf(stderr, "failed to create display!\n");
return -1;
}
al_clear_to_color(al_map_rgb(0,0,0));
al_flip_display();
al_rest(10.0);
al_destroy_display(display);
return 0;
}
When I attempt to compile and run the program an error message box appears saying "The procedure entry point _gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll." I searched the web for about an hour trying to find a fix for this problem, like I do for most things, but I came up empty handed. I'm wondering if anyone has any ideas for any fixes to this problem, if so, let me know ASAP! Thanks in advance!
__gxx_personality_v0 is used in the exception handling of the C++ library. MinGW can support a couple different exception models on the x86: sjlj (setjmp/longjmp) or DWARF (DW2). As far as I know, which model will be used is compiled into the compiler - it's not something that can be selected with a command line option.
The sjlj exception model will link to __gxx_personality_sj0, the DW2 exception model links to __gxx_personality_v0. It seems like your compiler is building for the dw2 exception model, but at runtime it's finding a libstdc++-6.dll that was built with the sjlj model. See if you have multiple versions of libstdc++-6.dll on youR system, and see if copying another one to the same directory as your program fixes the problem.
You can use nm libstdc++-6.dll | grep personality to see which exception 'personality' the DLL is using.
I ran into this as well. Did some searching, someone mentioned paying attention to whether or not you were in Debug or Release Mode. This applies to Code::Blocks specifically. I found I was in Debug Mode. I changed that to Release Mode and my program compiled and ran.
I am troubled by this though... It seems to me it should work in both modes, so how do I fix it so that it will? I have no answer there. Maybe someone will comment with the solution. In the meantime, compile and run in Release Mode instead of Debug Mode.
I just did a little mad science, removed the libstdc++6.dll from MinGW/bin and put it in another folder. Then I copied over the same file from Gimp/bin. No more linker error, instead I get an error that says the application failed to start :( Still compiles and runs in Release Mode though.