since there is no real tutorial on how to setup ImGui & SDL2, I came here to find answers.
I just have to paste ImGui file into my include folder to setup it right ? At least, it is what the ImGui readme file says.
When i try this :
ImGui::Begin("test");
I have this error :
undefined reference to `ImGui::Begin(char const*, bool*, int)
Code block do autofill me with ImGui functions when I start to write 'i'. Also when I do #include other files (ImGui_draw, etc. ...), I got only redefinition problems.
=> That's why my question sis lighty different from the already answered following question :
What is an undefined reference/unresolved external symbol error and how do I fix it?
So please do not close this question. I'm looking for a solution from 2 day now and a question here is my only solution left. I will have to give up on ImGui if this question is closed.. I'm truly clueless.
Could this error be due to a conflict with SDL2's opengl ? But in this case, shouldn't just the program crash instead ?
EDIT : Now this error is solved(I used to work with an IDE who include itself the files in my include folder, I didn't knew code block didn't), I have my program launching but nothing related to ImGui happens (as expected, I didn't figured out yet how to mix SDL2 & ImGui) and another error happens now when I quit my SDL2 window :
The program crashes and display the following in the console :
Assertion failed: g.Initialized, file C:\(...)\imgui.cpp, line 3882
Some random testes: If I use ImGui before my main loop it crashes there. Same inside the loop.
I just have to paste ImGui file into my include folder to setup it right ?
No. The header files are needed for your app to see what symbols are out there for valid compilation. But during linking, those symbols actually need to be there, and adding a single header file is not going to add them. You need to bring all the source files (cpp files and probably their corresponding header files) into your app and compile it all together.
Building a C++ app has two main stages: compilation and linking. Your header path has all the information for the compilation stage, but not for linking. Only actual source files (which are not header files) can contain the symbols needed to define what is declared in your headers. If you don't add those too, then your symbols are not defined, which explains your error.
Code block do autofill me with ImGui functions when I start to write
'i'.
That's because you included the header file, which is one part of the process.
I got only redefinition problems.
And just in case you are doing this, don't use #include with any .cpp files, only header files. If you #include cpp files in more than one place, you will definitely get multiple definition errors, as you indicated.
Quoting from imgui's README:
ImGui is self-contained within a few files that you can easily copy
and compile into your application/engine:
imgui.cpp
imgui.h
imgui_demo.cpp
imgui_draw.cpp
imgui_internal.h
imconfig.h (empty by default, user-editable)
stb_rect_pack.h
stb_textedit.h
stb_truetype.h
So you don't only need the imgui.h header, you need all of these file, taking care of compiling and linking the cpp files into your executable.
Related
I'm working on a library that links another library to use its static functions.
Everything was working perfectly until I switched from including all my code in the header file to sharing it between the .h and .cpp file.
I tried to use ./configure --prefix="<same path as before>" and then make install but ended up with a "/usr/bin/install: cannot stat .libs/<library name>.so.0.0.0': No such file or directory" error. (also, I did change my makefile to accommodate for the inclusion of the .cpp file)
Then, trying to compile my old library (which should've still worked since the linked library didn't make install correctly and was still technically using the older version) I get a pile of errors that seem to have to do with c++ itself. For example:
.../gcc/4.9.1/linux64/include/c++/4.9.1/bits/stl_bvector.h:354:13: error: expected ';' at end of member declaration
There are an absolute ton of errors similar to the one above, all having to do with issues in the path .../gcc/4.9.1/linux64/include/c++/4.9.1/
Has anyone run into this error before? Let me know if I need to provide any more information, it's just that I've never had this happen so I'm at a loss as to where to proceed. It's likely something simple I'm missing but the longer I stare at it the less it makes sense.
Thanks!
Update: I ended up solving the issue I was having. Basically, the .so file was not being accessed, so I used make clean and then the linked library compiled properly. Next, the issues with the base library was just an extra character within a header file that was causing the compiler to blow up with over 1500 lines of errors. After fixing that, it was able to link up properly and is working fine now.
This is my first stab at C++, also I know that the question is broad but I have a specific example that I'm working with so hopefully that will narrow everything down a bit.
I'm basically attempting to compile a C++ game manually in Linux (Ubuntu 14.04). The source code I am attempting to compile is located in this directory: https://github.com/akadmc/SmashBattle/tree/master/battle.
I'm CD'ing into the battle directory and, perhaps naively running
gcc *.cpp
I started seeing multiple issues as such:
compilation terminated.HealthPowerUp.cpp:1:21:
fatal error: SDL/SDL.h: No such file or directory #include "SDL/SDL.h"
and
compilation terminated.LaserBeamPowerUp.cpp:1:21:
fatal error: SDL/SDL.h: No such file or directory #include <SDL/SDL.h>
After researching header file includes I concluded that includes without <>'s are basically just relative paths to include a header file, and that when they are wrapped in <>'s they can either lookup the file through a listing of directories specified in an enviornment variable, or a command line option.
So my first question is, is there any reason the developer used
#include "SDL/SDL.h
AND
#include <SDL/SDL.h>
in different files? There was no SDL directory in the source code...
After realizing that SDL was missing from the source code / environment in one way or another I did tinkering. I was pretty confused (and still am) because I downloaded the SDL source files, didn't see any header files, ended up building a version of SDL by using cmake, and then build. I realized afterwards that I just made a local executable and didn't yield any header files. Then I realized that I just needed the development library, downloaded that, and put higher in the directory tree and then included it at compile with
c++ *.cpp -I $HOME/Desktop/smashProject/source/
Afterwards, the previous header file errors went away - but I started getting errors like the following:
Text.cpp:(.text+0x17): undefined reference to `SDL_RWFromFile'
Text.cpp:(.text+0x24): undefined reference to `SDL_LoadBMP_RW'
Text.cpp:(.text+0x34): undefined reference to `SDL_DisplayFormat'
And so on. Am I generally headed in the right path or do I have some misunderstanding about compiling, including development libraries, etc? Also I've read the the order of the compilation matters, and I'm not using any order + the developer didn't put a makefile in the source code or anything. I'm generally just confused as to how I should be doing this. Any help would be greatly appreciated.
Yes, you are on the right track. However, now you need to have a linkage to the SDL libraries. The -I just includes an extra library path but you have to actually link your assembly to the SDL files.
See this stack overflow question for more information.
How to compile an example SDL program written in C?
can someone please help me to understand the process.
in c++ visual studio 2010
i have a visual studio solution (lets call it mysol)
i have a project built as a static library (let's call it staticprj)
staticprj needs to use a library from outside (lets call it ext.lib)
in the body of the source code of staticprj i include outside library header file with
# include extlib.h and make calls to some of its functions (let call them extfunctions())
i also include the the path to the header files location of the ext.lib.
the staticprj compiles okay without errors
the mysol also has another project which is a dynamic library (dynprj) and which depends on the staticprj.
also in the source files of the dynprj uses functions from outside library.
i have included #include extlib.h in the source code of dynprj.
i have included the path of the header files
i have attached extlib.h directly to the dynprj
i have also added ext.lib to the linker input (along with the path where the ext.lib resides).
i still get a lnk2001 error stating that extfunctions() where not found.
the whole structure (the mysol solution) compiles okay if i do not use ext.lib at all.
my question is how does the linking process works and what can i do to correct this linking error.
(note that without the presence of ext.lib my linking of the staticprj and dynprj is fine. my compilation works okay and my code works. i only get the linking error when i try to link another ext.lib to staticprj and dynprj and use functions from ext.lib)
thanks in advance.
I'm not quite sure it will work, but try putting the .dll inside your "mysol" debug folder. I had a similar problem couple of weeks ago when I had library compiled as .dll. I just placed that .dll within my debug folder and worked lovely.
I just started learning C++ with Dev C++ as my IDE. One of the tutorials I'm using has a page in it about compiling a program made up of multiple files. It's simple stuff at this point, I have one file with a function in it, and the other file has all the other required code to call the function and output the results. The problem is that the tutorial doesn't tell me how to join these files so I can compile the program and have it work. There's seems to be multiple ways of doing this and I'd like them all but I'm mainly look for the simplest one right now.
I should also mention that I'm new at this so please try and keep your explanations simple and understandable.
In general, you would add both .cpp files to your project under the same target. It IDE will automatically add both files to the build and link them together.
That said, Dev-C++ is very, very old and unmaintained. It has not seen updates in several years. I strongly urge you to use a different IDE. There are many to choose from, including a fork of Dev-C++ called wxDev-C++. I'd actually recommend Code::Blocks or Visual Studio Express, which are both much more modern and have better support for debugging and many other features.
I am not sure of Dev-C++, but the concepts remain the same. So, here is how you can try to get both the files to work together
Each C++ file is a compilation unit - meaning, the compiler will convert one .cpp / .cxx file to one .obj / .o file (on Windows and Linux (or any Unix)) respectively
The obj files, called the object files contain the machine code (am skipping few internal details here) for the classes and functions present in that particular file
If you want to access the functions present in a different compilation unit, you need to link those two object files
Linking is a term that is used to, well, link two object files
There is a separate process (other than the compiler) which does the linking of the object files
So,in your case, you need to use the dev-c++ compiler and create separate object files
Then using the linker you link both the object files to create the final executable
If there are functions that exist in the .cpp files that you want to reference, you use the header files. The header files contain the function/class declarations. The .cpp files will have the implementations. So, in one of your .cpp file, (say) A.cpp, you include the header B.hpp and use the functions in the B.hpp file. The inclusion of headers will tell the compiler that the function declarations exist elsewhere and that the linker will take care of stringing all these references together to create the final executable.
Hope this helps, else, please don't hesitate to mention the files you are using and I can suggest how to link both the .cpp files together.
You must include the other files by using the #include preprocessor directive
in the top of the file where you have the main() function
For example:
#include "filename.h"
...
/* rest of code containing main function goes here */
...
#include "path/filename.c"
main
{
...
...
...
}
I'm using MSVC++ 6 to build a very large project. Some of the source files in this project are shared with a small utility that we use for maintaining the application. Previously, this small utility required linking against many libs from the main app and also required the main app's DLLs at runtime. I was tasked with removing these dependencies, which sounded pretty simple... unfortunately, the precompiled headers used in the main app are causing me a lot of trouble.
I first reworked all the files in the utility to explicitly include everything they need and then I removed the #include directives for the PCH (this removed 95% of the unnecessary dependencies for the utility). This works great for compiling the utility. Now, however, compiling the main app gives me errors about missing precompiled header directives. I thought "great, I'll just conditionally include the PCH". This does not seem to work... I get "unexpected #endif", as mentioned here. My next thought was to turn off PCH in the main app for the three source files that are shared between the utilty and the main app. This compiles successfully, but I get a bunch of errors that look like this during linking:
tls7d.lib(tls707d.dll) : error LNK2005: "public: unsigned int __thiscall RWCString::length(void)const " (?length#RWCString##QBEIXZ) already defined in stripledescypher.obj
AFAICT, all of the multiply defined symbols are ones that I explicitly include in the shared files to avoid the need for the PCH. My hunch is that since I'm linking those 3 files into the same DLL as the PCH .cpp file, they're compiled in multiple places. Is there any way out of this mess? I'll try just about anything...
When the compiler finds a definition of a symbol X when processing a compilation unit, it will create a hint for the linker: X is in here!
The compilation of two source files, both #includeing a header with a definition (i.e. not a mere declaration) will result in two object files defining the same symbol. The linker will find a symbol multiply defined.
So it appears that your stripledescypher object file includes a definition of the WCString::lenght()const method. This may be due to the function body being defined in the class' header or something the like.