I'm doing a tutorial on SDL, and I'm having some issues
I just did this where I do the basic stuff to get SDL to run. I then ran the test code (which is on that page) and it worked. However, now I'm trying to run the code here, and it's giving me this list of errors.
What could be the problem? There was one weird thing, I don't know if it's relevant, to get the first code running I had to put SDL2.dll in the SysWOW64 folder even though both my compiler and version of the library are 32-bit. Again, I haven't a clue whether that could mean anything, especially because I got the first thing to run perfectly.
Edit: Also, Code::Blocks shows me the error in SDL_platform.h, a file completely identical to my 01_hello_SDL.cpp. I'm a complete noob to SDL and even though I have done some pure C++ I haven't used it with an external library before, so I have no idea what that means.
Edit: Here's my setup:
I copied the contents of the 32 bit folder to C:\mingw_dev_lib\sdl, resulting in C:\mingw_dev_lib\sdl\bin, C:\mingw_dev_lib\sdl\include, C:\mingw_dev_lib\sdl\lib and C:\mingw_dev_lib\sdl\share.
I copied SDL2.dll to both C:\Windows\System32 and C:\Windows\SysWOW64.
In Code::Blocks my setup is like this: In build options, in the linker settings tab I put -lmingw32 -lSDL2main -lSDL2. In the search directories tab, in the Compiler subtab I have C:\mingw_dev_lib\sdl\include\SDL2 and in the Linker subtab I have C:\mingw_dev_lib\sdl\lib.
This got the test (which you can find at bottom of the page of first link) to work. However, the second program (at the bottom of the page of second link) gives me the errors in the third link.
First of all you need to put SDL2.dll in the SysWOW64 folder because you're linking SDL2 dynamically and when you execute the program it needs to find the SDL2.dll file in basically two folders:
The folder where the program resides.
System32 (or his 64 bit counterpart SysWOW64).
Therefore i can't give you an accurate answer based on the compilation errors you get, please show how you're including SDL2 and the Code::Blocks configuration.
Related
I'm following the gtkmm tutorial for gtkmm4 and I'm getting an odd error when I try to run my program. The program is an exact copy of the provided code, and it compiles successfully:
However, when I run the program it gives me a series of errors:
I'm not sure what to do at this point. I've tried googling, but I don't get anything helpful. I've check that the DLL in question does exist. Any advice is appreciated!
Edit: I ran the Dependency Walker program, and got some errors, not sure what this means though.
Edit2: I did some research on Dependency Walker, and it seems to have some known issues, so I also ran lucasg's "Dependencys" program, with this output. I'm still not really sure what this means, but it seems fine.
Edit3: I moved the 4 offending dll files into the build directory, and these are the new errors I'm getting. Its the same error, but now it points to the more local file.
Check your .exe file with Dependency Walker to see which issues there are loading the .dll files.
One possible cause could be that you're mixing 32-bit and 64-bit.
The issue was something to do with finding the correct DLLs. The solution, as outlined here, is to copy all the DLLs from C:\msys64\mingw64\bin into the build directory. Then, using ntldd or some other profiler, determine which DLLs are unnecessary and remove them.
I'm creating a library for the first time. So far it's working from the IDE (Qt Creator), but not from the terminal when I run its testing program manually.
There are two parts to my project, the library, and the sandbox for testing it. I've created a project in Qt Creator that includes two subprojects (one to build the lib, and one to build the tester) and both compile without errors. When I run the sandbox from the IDE the library is dynamically linked to the sandbox, the function greeting() is loaded in from it, then called, and prints "Welcome to the library!" to std::cout. However, if I open the build folder in the terminal and run the sandbox directly using ./sandbox I get:
./sandbox: error while loading shared libraries: libengine.so.1: cannot open shared object file: No such file or directory
I took this to mean that I needed to properly install my custom library, libengine.so.1. When I looked up how to do that I found that I just needed to copy the library files in to either, /usr/lib or /usr/local/lib, but neither of those worked and I'm still getting the above error. In the past, that simple solution did work for me when compiling a 3rd party library (SDL, I think) and I don't know what I'm missing that would mean it wouldn't work now. So far I haven't yet found any more detailed information and I don't know what I'm doing wrong or have missed.
How do I make my sandbox program see its companion library when I run it directly from the command line?
NOTE: I'm specifically asking about Linux/Ubuntu. If I later run into problems under Windows I'll be back. :-)
Short Answer
I ran in to multiple problems all at once.
First problem: Broken symbolic links (they're like shortcuts in Windows).
Second: My lib needed to be copied in to a different system directory than is generally recommended.
Third: Qt Creator and QMake made passing custom linker options difficult.
The Details
When Qt Creator compiles my library it automatically creates three symbolic links to it with different layouts of the version numbers.
> ll
lib-engine.so -> lib-engine.so.0.1.0
lib-engine.so.0 -> lib-engine.so.0.1.0
lib-engine.so.0.1 -> lib-engine.so.0.1.0
lib-engine.so.0.1.0 (original library file)
For some reason (I don't know why) each time I moved the links in to a system directory like usr/local/lib the links would break. I didn't notice this at first, or even think to check, because that's never happened to me before. Moving a link has always worked in the past. To get around this I just manually created the links within the directories they would reside in.
Broken links aside, putting the library in to usr/local/lib still didn't work, but usr/lib and /usr/lib/x86_64-linux-gnu (recommended in the blog linked below) did work!
Those fixes actually came after a different fix I looked in to after reading this blog and this article it linked to.
There it said to add -Wl,-rpath,'$ORIGIN/lib' to the gcc build options to embed a library search path in to the application itself. This set of options would allow me to put my library files where ever I wanted (specifically, in a directory called /lib in the application's working directory).
Unfortunately, that had two problems of its own. First, Qt Creator doesn't (from what I can tell) allow you to specify custom build options for individual subprojects through the GUI, so I had to figure out how to add linker options using the project file, assuming that was possible, which it was.
Second, QMake messed up the gcc options, embedding in to my application Library rpath: [RIGIN/lib] instead of Library rpath: [lib] like it's supposed to.
In the end, changing the proposed linker options of...
-Wl,-rpath,'$ORIGIN/lib'
... to the following QMake project file line...
QMAKE_LFLAGS += -Wl,-rpath,'lib'
... work out nicely. Using both fixes I can now either install my library on my system or put it in to a /lib folder and the program will run.
I can compile my program in Code::Blocks 13.12 (MingW (haven't tried other versions)) and run it within the IDE.
However, when I attempt to run the program outside the IDE I get
libgcc_s_jlj-1.dll missing
Reading around I have tried adding
-static-static-libgcc-static-libstdc++
to my linker settings (individually and I used the last two together) which doesn't work
If I copy the .dll files to the same folder as the .exe it presents
libstdc++-6.dll missing
to my attention. If I copy /that/ .dll too the program will run just fine; however, I'm not sure the legality of moving the .dll with my program, and I want distribute my program easily to others so the static option I read about seems preferable.
(side note: I shouldn't have this error so I'm curious as to what I'm doing wrong)
Why would a project be able to compile and find the necessary header files, and then I add a line that it cannot find, it does not compile, I remove that line (the code now looks exactly as it did when it compiled the first time) and now suddenly it cannot find the header files that it could find only a moment ago? I did not change any of the file structures, absolutely nothing changed other than adding a line, removing it, and everything is broken.
I have followed every instruction in the Ogre3D tutorials up to building the first tutorial. Everything works perfectly fine and the first tutorial compiles and runs. So I decide to see if I can get a different tutorial to do the same thing, but alas the compiler throws an error: No such file or directory when looking at the line #include "Ogre.h". So I go back to the first tutorial's framework, I include all the lines and it still compiles as expected and then I decide to remove all of the source files and everything, and I take the very first include directive from the BaseApplication.h, the line is #include <OgreCamera.h>, and I put this lonely line in a single file main.cpp and attempt to compile this 1 line program. The same error occurs, it cannot find OgreCamera.h! What??
So what is so special that the tutorial framework compiles but when I try to do basically the exact same thing it throws a fit.
Update
Even stranger things are happening now... I added the line #include "Ogre.h" to the tutorial framework's BaseApplication.h file, it cannot find Ogre.h. So I remove that line and try to compile the program (which compiled not more than 10 seconds ago) and now it no longer can find OgreCamera.h! But it has literally not changed at all in any shape or form that I can tell. This is confusion of maddening proportions now!
Where the header files are resolved from is not defined in the code itself, but in the IDE and/or code::blocks project preferences. This tutorial is more relevant for setting up the search directories for Ogre header files.
If it was working a short while ago and not now, I would suspect you have probably made a simple mistake like switching from Debug to Release, having only configured the search directories for Debug build in the project properties. (Clicking build options defaults to selecting Debug rather than all configurations). Try to re-add the Ogre directories in both Debug and Release builds.
Code::Blocks also lets you add search directories globally for the IDE, in the compiler and debugger settings for commonly used libraries. You can also create a global variable for the Ogre SDK location to make it simpler to add to each new project. (#ogre.include), rather than adding the full/relative path.
I believe I know what I have done to myself here.. and recreated the problem
I followed the tutorials and setting up an application to the letter, and was having some other problem when I decided to copy the entire project I had already made doing the tedious setup things necessary. Without realizing that copying the entire project by simply copy-pasting the directory does not carry the tedious setup things necessary. And so, probably without paying attention to the "Target is up to date." build message, assuming it compiled I changed the files, it did not compile as expected, and then changed them back to their original state, and it still did not compile because they were no longer up to date.
I am going to remember this... for a long time.
I have updated my Ubuntu box to 11.10 and then Eclipse also have been updated to 3.7.0 Indigo with CDT 8.0.1
Then the following problem occurs:
I have included the vector header file but the compiler said that Symbol 'vector' could not be resolved. I also defined #define int Comparable, but Eclipse also said Symbol 'Comparable' could not be resolved and so on....
Although lots of errors occur, compiling was finished successfully!
I have tried to use g++ to compile the code, it had no problem.
The problem is that there are a bunch of include directories that are missing from the indexer's perspective.
Adding the following worked for me, but may depend on your particular setup where they actually exist:
/usr/include/c++/4.6.1
/usr/include/
/usr/include/c++
/usr/include/c++/4.6
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/
They can be set in Project>Properties>C++ Include Paths
Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.
Time after time a crash of Eclipse, the VM or the computer or even just long months of development start to wear down the stability of the workspace where Eclipse stores everything.
Check the <workspace dir>\.metadata directory to get an idea of just how much Eclipse generates and stores in your workspace. Every time you add a plugin, upgrade a plugin, remove a plugin that puts and changes information in your workspace.
A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).
The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.
Eclipse help docs tell us what this command does:
if set to "true", any cached data used by the OSGi framework and
eclipse runtime will be wiped clean. This will clean the caches used
to store bundle dependency resolution and eclipse extension registry
data. Using this option will force eclipse to reinitialize these
caches.
There are three ways one can use the -clean command line argument:
Edit the eclipse.ini file located in your and add it as the first argument on the first line.
Edit the shortcut you use to start Eclipse and add it as the first argument.
Create a batch or shell script that calls the Eclipse executable with the -clean argument.
The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.
This page solved the problem to me!Hope it can help everybody else.
In the project properties, go to C/C++ Build > Tool Chain Editor, tick Display compatible toolchains only, and select Linux GCC and click Apply button.
Now if you go to C\C++ General > Paths and Symbols, you will see new list of include paths added. If you rebuild index, the error messages should go away.
The code analysis is causing this. It's not actually compiling the code but just doing some static checks for quick feedback. Unfortunately I don't know how to fix it, I just disabled it. Sorry I'm at work so I don't have CDT in front of me but I think it's something like:
Window > Preferences > C++ General > Code Analysis
Go there and un-check all the boxes to disable it.
When you create a C++ project (in my case from existing code) you have to set the 'Toolchain for Indexer Settings' to the compiler you use ('GNU Autotools Toolchains' in my case).
After this 'Path and Symbols' will show the correct path to the include files of your compiler.
The bugs will disappear.
This setting was useful only during creating the project, setting it later did not help.
In indigo 3.7.2 version (and up may be) your changes can be effect after reindexing. Eclipse ask for "reindexing". Lower versions can require a manual reindexing header tags etc.
Updated index option to active build configuration works for me,
also I removed some files from the file list of being indexed up-front,
Ok here is what worked for me:
deleted the path to the header files I created from the include path
compiled the project (obviously the compiler complains since it is missing user-defined headers)
reinserted the path to the header files I created
compiled the project again - worked perfectly
I can't explain the case :(
I am answering here because this is the closest question to my problem.
I used QT Eclipse integration with Helios (3.6.2) with no major problems. I was using mingw 4.6.2, which I had installed to c:\mingw. I wanted to upgrade to Indigo, which fixed some minor issues I was having with CDT.
However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:
function 'fprintf' could not be resolved
function 'memset' could not be resolved
even though #include was not underlined, could be opened, and included fprintf in the header. And even though the code itself compiled fine.
If I went back to Helios, the problems went away.
I tried reindexing, to no avail. I checked my include paths, and they were:
c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include
At first, I had just included the first, but not the second. But then I searched for "unresolved includes", and stdio.h was including stdarg.h, which wasn't in the main include folder of mingw, so I added the second. But still, printf was not resolved, and there were no more "unresolved includes".
I created a new C++ project with one class. I added stdio.h, the paths above, and a call to fprintf. It was underlined! Even though other things from stdio were not underlined.
Now I knew that it wasn't just a Qt problem.
I worked around on this for a while before I read the bottom post here suggesting removing the include paths and compiling. I didn't believe it would work but gave it a shot. Amazingly, even though the compile failed, the error went away!
It was then that I took another look at the include paths. They had been updated by the compile step to the following:
c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++
These were marked as "built-in" values which I assume means they weren't added by me and could get updated the next time I run a build.
So, I guess the lesson is, including every single include path under mingw, even if Eclipse doesn't find it to be an unresolved include.
The next step was to put all these paths into my Qt project. Unfortunately, after doing so, the unresolved functions were still there. It appears to be some sort of bug with the Qt C/C++ include paths which are different from the CDT C/C++ include paths.