Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 5 years ago.
Improve this question
I'm trying to create a C++ application with SFML. Followed the tutorial, installed MinGW for Windows. My project has a main.cpp file in its root folder, and SFML is included in lib/sfml (relative to main.cpp).
I can compile without problems with the command g++ -c main.cpp -g -o build/debug/game.o -Ilib/sfml/include
But I get undefined references when I try to link wit the command g++ build/debug/game.o -o build/debug/game.exe -Llib/sfml/lib -lsfml-graphics-d -lsfml-window-d -lsfml-system-d
Some of the errors:
C:\Users\andre\Documents\Repos\Game/main.cpp:5: undefined reference to `_imp___ZN2sf6StringC1EPKcRKSt6locale'
C:\Users\andre\Documents\Repos\Game/main.cpp:5: undefined reference to `_imp___ZN2sf9VideoModeC1Ejjj'
C:\Users\andre\Documents\Repos\Game/main.cpp:5: undefined reference to `_imp___ZN2sf12RenderWindowC1ENS_9VideoModeERKNS_6StringEjRKNS_15ContextSettingsE'
I've searched already and nothing seems to help me. What I found strange is that in some previous versions of SFML it came with more libs inside the lib folder, like opengl32.lib. Still, it says that, for example, sfml-graphics I need:
sfml-window-s.lib
sfml-system-s.lib
opengl32.lib
freetype.lib
jpeg.lib
The only one missing is opengl32.lib. If I consider sfml-system and sfml-window, it is missing too winmm.lib, gdi32.lib. I don't know if this has something to do with the errors, but any help is welcome.
Solved, my mistake. I downloaded some days ago the SFML version for Visual C++ compiler, but then I gave up on Visual Studio 2017 and decided to use Visual Studio Code with GCC. So I tried to use the SFML I had thinking it was the right one. Now I've downloaded the right version and it is working perfectly.
If you're linking the static version of SFML, SFML's header files have to know about this (since the function signature changes slightly). As such you'll have to define SFML_STATIC somewhere before you include any SFML header, ideally as part of your project, make files, or build system.
In addition, you'll have to make sure to link the proper versions of the libraries and those you actually want to use.
As an example for the system library:
sfml-system is the shared release build of the library.
sfml-system-d is the shared debug build of the library.
sfml-system-s is the static release build of the library.
sfml-system-s-d is the static debug build of the library.
You'll only have to link SFML's dependencies (such as OpenGL), if you're linking the static version of SFML.
SFML never shipped with OpenGL, you're probably confusing it with OpenAL-soft. Either way, the additional library files you're missing are either provided by your toolchain/system (like OpenGL or mmsystem) or can be found precompiled in SFML's extlibs/libs folder (depending on whether you've downloaded or compiled SFML yourself).
Related
As the title says, I've been trying to cross compile a fairly large project with quite a few dependencies (both static and dynamic libraries). I've cross compiled every dependency successfully using MinGW-w64, set the include & library search paths to their MinGW counterparts (/usr/x86_64-w64-mingw32/lib & include), and yet on the linking step MinGW throws out an error for each call of printf (with stdio.h included, of course). The errors are as follows:
/usr/bin/x86_64-w64-mingw32-ld: ./obj/XXXX.o:/usr/share/mingw-w64/include/stdio.h:352: undefined reference to `__imp___acrt_iob_func'
(Where "XXXX" is a file name from my project)
This error is repeated the exact same (with the exception of the object file name). The command for linking looks like this:
/usr/bin/x86_64-w64-mingw32-g++ -o bin/ReleaseWin/Project #[file with object file names] -L. -L/usr/x86_64-w64-mingw32/lib/ [linking some dependencies (boost, openGL, SDL2, etc.)...] -m64 -flto
I've searched for a solution (or even someone with the same problem) to no avail. I've never been well-versed in linking any more than regular libraries, so if you need more information just ask.
Thanks in advance :)
Extra info:
This project has been cross compiled (from Linux to Windows) successfully before, and I haven't added/removed any dependencies since.
My MinGW-w64 version is 7.0.0
So, I apt-get purge'd mingw-w64 and mingw-w64-common, reinstalled just mingw-w64, and now it's working...
This might have something to do with the fact that I followed the issue that Richard Critten commented with (thanks!), which led me to try downloading and manually copy/pasting headers and CRT (mingw-w64-x86_64-headers-git-... & mingw-w64-x86_64-crt-git) from the MSYS2 repository. That didn't work right away (probably because I screwed up and used the 5.0.0 versions instead of my version), but it seems to have done something.
Therefore, for those who stumble upon this issue,
Try a re-install of MinGW (of course),
Try manually adding the CRT and headers from the link I supplied, and if that still doesn't work,
Try re-installing MinGW again. I'm not super familiar with apt, so I don't know if adding the CRT and headers actually changed how it installed MinGW, but it's worth a shot I guess.
Update: I had this exact same problem on another system. Simply reinstalling MinGW fixed it, so it seems like maybe there was some sort of issue with the files? It's possible that updating from an earlier version messed with things. Moral of the story: even if you think your files are good, a reinstall can't hurt.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
(I've just edited the question to be more specific)
I know that this question might be too general to answer, but I'm just can not find good tutorial on this, so trying to seek for help here.
I'm new to C++, previously my main programing language is Java and Python. The way that C++ manage third-party lib is somehow confusing for me......While Python can easily install things with pip, Java can import the JAR, how C++ organize those things?
I would like to split my question into few parts:
Here is some understanding and question of mine:
As long as the compiler, or IDE, know the path of the lib, then everything is fine. So when saying install, we just add the path of the lib to some system path. And for IDE, we just config the setting so that it can resolve the lib in given path. Correct me if anything is wrong.
Some C++ lib are all source code, and some contains sth. like .so or .dll, what is that? And what's the difference? I saw some lib saying that it can be used with simply include a few headers, but some require static linking, what does it mean?
What's is a general good approach to manage all those lib? (For example, in python, pip will simply install to some global scope, or we use vitrual env to manage that. Then anything similar to pip in C++?
More specifically, I'm using CLion, and Clion use CMake, so maybe all I suppose to do is config the CMakeList.text correctly and then the IDE will resolve all lib and compile correctly?
Again sorry for such general and somehow opaque question, but I'm totally lost as a newb for C++, which is much more complicated than Python and Java I used before.....
Any good tutorials might be of great help, thanks!
C++ doesn't. C++ is a language not a specific compiler or implementation.
With that said, for most compilers, building a C++ application is done in multiple steps:
Edit
Compile to object file
Link to executable.
The C++ compiler is technically only involved in step 2 (and really only part of step 2).
Most compilers and linkers since long ago allow you to put header- and library-file anywhere, and then there are flags passed to the compiler and linker on the command-line that tell the compiler and linker where to find the files.
For header files the (common) command-line option -I (upper-case i) is used to add a path to be searched for header files. For libraries the option -L similarly adds a path to be searched by the linker for libraries. There are of course default paths built into the compiler and linker, and the -I and -L options adds to those defaults.
Then to link with an actual library, the linker-option -l (lower-case L) is the common option to use. Each -l options list a single library that needs to be linked into the executable.
In regards to CMake and CLion, the CLion IDE doesn't really link anything at all. Instead it uses CMake to create a set of makefiles which contains the information used to build the targets.
Lastly there are some C and C++ alternatives to PIP or other languages package managers, but generally you use the standard way to install programs and libraries on your system.
Like on Windows you find an installer, and then modify your project settings (using CMake CMakeLists.txt, raw Makefile, or IDE settings) to add the directories needed.
For Linux systems you use the standard package manager (like apt on Debian-based systems, or yum on Fedora-based systems, etc.) to find and install libraries. Then the libraries and their header files will be installed in the default locations. You still need to set up the build-environment to actually link to the libraries.
The common way is, that you include the thirdparty stuff as a .dll or you can include it direct as code (as example boost ... you have to load it and to make it work you only have to include the parts you want, and for some parts from boost you have to build it with your compiler settings and include the .dlls)
The thing with the manager like you want I only now from VisualStudio with NuGet. I have no idea if is there such a thing for CLion.
As example you can look to the example from opencv:
https://docs.opencv.org/master/d3/d52/tutorial_windows_install.html
For your questions:
Correct. But in case the lib have to match also the settings (32/64 bit, release/debug)
If you only have to include some headers, then the code is direct included to your project and compiled with your code. If you have to link it as a binary (.dll windows, .so Unix (i think please correct me if wrong)) than the code is compiled and you link the compiled functions to your code.
Here a answer to .so:
What are .a and .so files?
And here for static and dynamic libs:
When to use dynamic vs. static libraries
I've recently been trying to make use of the boost libraries and whilst I have been able to include header-only libraries just fine I'm now stuck on including the linked libraries. I've managed to use b2 to build the libraries with gcc and then link to them, but whilst trying to include thread I get these errors.
I've read that these errors can be caused by using the wrong toolset for building but I can't see how I could of got that wrong as I've only ever used mingw and I used toolset=gcc when building. Here are my toolchain executables just in case I have done something wrong there. What am I doing wrong?
Turns out my path variable was incorrect and included Haskells mingw directory instead of the one I was using. After getting rid of Haskell from my path and adding the directy of the version mingw that I was using everything worked as intended.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
The program can't start because libgcc_s_dw2-1.dll is missing
I'm using Code::Blocks and MinGW 4.4 (I think) compiler to create a C++ project. I get this system error if I run it from its directory, but not from within Code::Blocks.
The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
In this post hardmath said to add -static-libgcc to the compiler flags, linking to the dll statically. When I tried this the error still occurred. I could get it to work by adding the MinGW bin directory to my computer's Path variable, but I plan on distributing my program across the internet.
The issue only appeared after updating to the latest G++ compiler. What's the reason for this solution working for everyone else apart from me?
The link commandline argument -static-libgcc should work. Another variant you could try is plain -static.
If you don't want to worry about this, and still want to redistribute your binary, just copy the relevant dll from MinGW's bin directory and place it alongside your executable. This is common practice and works as advertised.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
The program can't start because libgcc_s_dw2-1.dll is missing
I'm using Code::Blocks and MinGW 4.4 (I think) compiler to create a C++ project. I get this system error if I run it from its directory, but not from within Code::Blocks.
The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
In this post hardmath said to add -static-libgcc to the compiler flags, linking to the dll statically. When I tried this the error still occurred. I could get it to work by adding the MinGW bin directory to my computer's Path variable, but I plan on distributing my program across the internet.
The issue only appeared after updating to the latest G++ compiler. What's the reason for this solution working for everyone else apart from me?
The link commandline argument -static-libgcc should work. Another variant you could try is plain -static.
If you don't want to worry about this, and still want to redistribute your binary, just copy the relevant dll from MinGW's bin directory and place it alongside your executable. This is common practice and works as advertised.