I'm learning SDL through Lazy Foo's tutorial, but I can't proceed further as IMG_Load doesn't seem to work. I tried setting it up like he says, but it just doesn't work. I put all the include files into include folder, and all the lib files into the lib folder. What I found is that there were x86 and x64 folders in the lib folder. When I tried x64 (because I have a 64-bit system)it all worked fine, CodeBlocks even told me suggestions (like when I wrote "img" it showed up a suggestion "IMG_Load" (which means the library got initalized?)), but when I come to compiling my code, this happens: http://puu.sh/3Eqa5.png. When I try with the x86 version, exact same error.
I had a little search around the internet, and all I could find were a few threads, but most of them were abandoned. The closest I got to answering my problem was this: http://www.dreamincode.net/forums/topic/118299-sdl-image-error-sdl/ but the guy solved his problem by downloading a problem which Linux can use, not Windows.
}
I'm running Windows 7 64-bit, CodeBlocks 12.11, SDL 1.2.15 and SDL_Image 1.2.12.
I really don't know what the problem is!
You should go to the Compiler and Debugger settings again and under the Linker Settings tab paste:
-lSDL_image
In addition to the #Aleeee's answer, a command line solution is to add -lSDL2_image compiler flag (SDL2 is the up-to-date version by the time of this writing).
Compilation example:
gcc -o object_file_name source_file_name.c `sdl2-config --cflags --libs` -lSDL2_image
It turns out the SDL_Image library I was using was buggy. I don't know how that happened though. I just had to use a older version. Thanks to anyone who helped!
Related
I'm trying to compile a C program using Ncurses on Windows. I compiled it successfully using GCC and it works perfectly if I run it in Cygwin or MSYS2. However, if I try to run it in the Windows Command Prompt, I get this error:
Error opening terminal: xterm-256color.
Is it possible to compile it to run using the native Windows console? This is how I've been compiling it:
gcc -o PROGRAMNAME main.c -lncurses
I also have the Cygwin and Msys dlls for Ncurses copied into the directory of the compiled executable.
Update
So I figured out how to get the program to run. I deleted all the DLLs from the project folder and then added "C:\msys64\usr\bin" to my PATH environment variable. However, I would still like to know if there's a way to get this to work if I were to distribute it, since it's still relying on my installation of MSYS2.
Update 2
Gave up and just used pdcurses and it works fine.
Update 3
Nevermind, found a solution! See below.
I figured out a solution. I'll post it here in case anyone else has this same issue. Thanks to Thomas Dickey for your help!
Install the mingw-w64 toolchain and any other packages you need to compile your project (this is mostly where I messed up)
Make sure to include the /mingw64/include/ncurses directory when compiling, or else gcc won't be able to find curses.h
Include /mingw64/bin as a static directory or copy over the necessary dlls to the same folder as the directory
I ended up with this to compile:
gcc -I/mingw64/include/ncurses -o PROGRAMNAME main.c -lncurses -L/mingw64/bin -static
I am compiling an app for 32bit machines since the creator of the app made it 64 bit. I made sure all the libraries and DLLs are 32bit, which they are. I have an issue when I compile, however. When I compile using sh make.sh, I get an error when it gets to the GCC building part. make.sh just makes sure that all the needed libraries are there for this project. There's no errors in the Makefile, make.sh, or any of the C++ files. I've been wasting hours trying to figure this out.
Here's a screenshot if it helps:
Needed to enable -D_WIN32 os flag in make.sh.
I have a custom library that utilises this code (https://www.dropbox.com/s/iwft7snjmntf160/SoASpriteFont.zip?dl=0).
The linked code was written for Visual Studio; I am using CodeLite on Windows.
Its has a SpriteFont.cpp that uses fprintf.
The static library that has SpriteFont as part of it compiles fine on its own and produces a *.a quite happily.
However when I use SpriteFont via other code, I get a linker error (if I am not mistaken):
D:/Coding/TDM-GCC-32/bin/g++.exe -o ./Debug/tmp #"tmp.txt" -L. -L../deps/lib/ -L../bengine/lib/ -lbengine -lSDL2_ttf -lSDL2main -lSDL2 -lopengl32 -lglew32
D:/Coding/TDM-GCC-32/bin/../lib/gcc/mingw32/5.1.0/../../../libmsvcrt.a(dsnos00619.o):(.text+0x0): multiple definition of `fprintf'
../bengine/lib//libbengine.a(SpriteFont.cpp.o):D:/Coding/TDM-GCC-32/include/stdio.h:243: first defined here
I have read all over and found some similar situations but nothing that I have managed to use to resolve this.
It sounds like there is an issue with the way TDM-GCC redefines fprint in its' stdio.h, but I can't see how. Upon further examination, I believe the problem may lie with SDL_ttf, which is used by SpriteFont.
Also, I have tried using other functions from stdio.h and they compile fine; problem only seems to be fprintf
I have tried to create a barebones program to illustrate the problem. Hope it helps. Hopefully the fact it is a CodeLite project won't be a source of irritation.
If I can provide more info or code please ask.
This usually happens in MinGW when linking against a dll file that also has file in the form of <NAME>.dll.a
To fix this, just link against the dll directly (I recently encountered the same problem when build LLDB debugger on Windows /w MinGW, the solution was to link directly against the dll file and delete the dll.a file
Just recently I tried to install GTK+ on Windows 7 using all-in-one bundle and latest MinGW package. I proceeded with all steps of official tutorial. Lurking through several tutorials, especially this one helped me getting MinGW and MSYS set up, so GCC sure works. The command
pkg-config --cflags --libs gtk+-3.0
printed out the expected set of paths/options. However, when I tried to run either
gcc -o gtk3.exe gtk3.c (pasted 'pkg-config' output)
or
gcc -o gtk3.exe gtk3.c `pkg-config --cflags --libs gtk+-3.0`
I've got
gcc: error: gtk3.c: No such file or directory
as a result. Searching the file manually was no success as well. It seems that Windows command prompt has torn the original long command apart, but I don't think that it would be this way if GCC has initialized gtk3.c.
I believe that official tutorial can't be wrong, so please help me resolve this problem.
Best regards, Mathias.
A Windows installation tutorial for GTK+ might not be the most thoroughly tested thing... This is a better version of that page, it includes a link to the source file (although any GTK+ "hello world" code will do).
You could file a bug on the missing link and images as well if you want to help others.
I have build a g++ v4.4 from source by using the archives provided by gcc.gnu.org.
But the resulting g++ cannot compile some of our projects c++ files. I am receiving a message simply saying: assembler error. It turned out that the assembler chokes on some extremely long symbol names, e.g. symbols names with a length of more then 2k.
Am I missing something to get it to work?
I would very appreciate an advice on how to get this working!
Environment: Debian-Lenny 64bit
EDIT: The mentioned c++ files are compiling fine with g++ versions v4.2 and v4.3. So I don't think it is a bug in the assembler (from binutils v2.18). Just to be sure I have also tried with binutils v2.20 - but I got the identical error message.
EDIT: I need g++ v4.4.x for the purpose of comparing the output of different g++ versions (and there is no g++ v4.4 in the official lenny repositories)
If your analysis is correct, it seems the proper course of action would be to file a bug for binutils. Or gcc, if it turns out the long symbol names are due to a bug in gcc's name mangling.
Of course, a (preferably reduced) testcase will help the developers fix your problem. Heck, it could have helped SO readers to verify your problems.
You're going to have to compile the corresponding gas instead of depending on what lenny has in his refrigerator (/usr/bin).
Why don't a) upgrade or b) use the backports archive or c) rebuild from current Debian sources on your box? I happily run testing with g++ 4.2, 4.3 and 4.4.
Worst case, you could install a new Debian release in a virtual environment such as a chroot, a Xen or Kvm instance, or inside VirtualBox.