I want to learn OpenGL programming with GLFW library. But I have problem when compiling the program. I followed tutorial on http://www.glfw.org/docs/latest/quick.html and copied the full program. I download the 64-bit version library on http://www.glfw.org/download.html.
I changed the first line from include <GLFW/glfw3.h> to include "GLFW/glfw3.h". I've put the GLFW folder inside the folder along with glfw3.dll, glfw3dll, and libglfw3.a
I'm running on Windows 7. This is my gcc version
gcc --version
gcc (tdm64-1) 5.1.0
I use this command for compiling
gcc test.c -Llib-mingw/ -lglfw3 -lopengl32 -lgdi32
But I got this error
cannot find -lglfw3
What should I do to make it work?
If you are still having problems with this compilation/linking problem, try set the glfw full lib folder path in gcc or g++ lib path with -L parameter, as simplified below. Double quotes and non-relative paths should work.
g++ "-L<path_to_glfw>\\glfw\\lib-mingw" -o <executable>.exe <.o files list> -lopengl32 -lglfw3 -lgdi32
Two notes:
There is no need to pass .a extension. MinGW g++/gcc compiler will automatically understand filename.
If you are using the 64-bit version of glfw, switch -L parameter to \glfw\lib-mingw64 (or respective 64-bit library location folder)
Related
I downloaded SDL for MinGW here : https://www.libsdl.org/download-2.0.php.
But when I try to compile with gcc it can't find the libraries.
It says it cannot find "SDL2/SDL.h".
I tried running GCC with the parameters to include the path after moving the folder containing
SDL2 to the same directory of the project.
I used this command:
gcc main.c render.c sprite.c logic.c menu.c level.c -o release -l:SDL2\x86_64-w64-mingw32\lib\libSDL2main.a -l:SDL2\x86_64-w64-mingw32\lib\libSDL2.a -ISDL2
If you want the compiler to find the libraries, you need to include the directory it is in using -I/dir/
I'm running a Debian (Buster) container and my goal is to compile a small program I wrote which relies on libgit2. First, I was installing libgit2 via the libgit2-dev package and my Makefile had the following:
gcc -O2 -fpic -shared -I /usr/local/include -lgit2 -o output.so my_app.c
However, I'd rather have a "cleaner" environment and install libgit2 via the libgit-27 which, AFAIK, only installs the shared object binary instead of also including the development files like libgit2-dev does.
Using find I can find where the .so file is installed into:
$ find / -name "*git2*" -print 2>/dev/null
/usr/lib/x86_64-linux-gnu/libgit2.so.0.27.7
/usr/lib/x86_64-linux-gnu/libgit2.so.27
/usr/share/doc/libgit2-27
/var/lib/dpkg/info/libgit2-27:amd64.list
/var/lib/dpkg/info/libgit2-27:amd64.symbols
/var/lib/dpkg/info/libgit2-27:amd64.md5sums
/var/lib/dpkg/info/libgit2-27:amd64.shlibs
/var/lib/dpkg/info/libgit2-27:amd64.triggers
and I've been trying several combinations of linking this .so with gcc like:
gcc -O2 -fpic -shared -L /usr/lib/x86_64-linux-gnu/ -libgit2.so.27 -o output.so my_app.c
but so far I always get the following error:
my_app.c:1:10: fatal error: git2.h: No such file or directory
#include <git2.h>
^~~~~~~~
compilation terminated.
I understand this is a glaring lack of knowledge on how C compilation works. My two questions are:
Is it possible to compile my program by just relying on the libgit2-27 Debian Buster package instead of libgit2-dev? If not, why?
If yes, an example and explanation would be appreciated!
I've used linuxbrew to install gcc 5.3 on a machine on which I don't have sudo access. I now want to link with X11:
> gcc test.c -lX11
ld: cannot find -lX11
I've checked that libX11.so exists in /usr/lib64/ which is on the compiler's LIBRARY_PATH. If I use the system's gcc it works fine, but I need a newer version to compile my actual program.
use -L flag, like this -L/usr/lib64, or you can specify full path to library like this gcc test.c /usr/lib64/libX11.so
According to this comment by a linuxbrew developer,
linuxbrewed gcc removes /usr/lib64 from the library path because mixing system libraries with brewed libraries creates havoc.
The solution is to brew install linuxbrew/xorg/xorg.
I'm using MinGW on Linux (Ubuntu, specifically) to compile a C program for Windows. I'm using a library called SFML, and it's bindings called CSFML. I'm using -L and -l to locate the libraries, but when I compile I get this error:
win32/dll/csfml-audio-2.dll: file not recognized: File format not recognised
I've got no idea why. Here's the command I'm using to compile:
sudo i686-w64-mingw32-gcc -o wandering src/main.c src/constants.c src/Display/display.c **...some more c files in here...** src/Generation/perlinnoise.c $(pkg-config --libs --cflags glib-2.0) $(pkg-config --libs --cflags gee-1.0) -Iwin32/CSFML-2.1/include -Lwin32/dll -lcsfml-audio-
Does anyone know why it's happening? I can compile C programs without SFML but with MinGW just fine...
The DLL has a PE32 executable file header. It's not used for the linker. You should use the import library instead. This file has the extension LIB.
I heard there are some gcc compiler versions out there than generate an import library from a DLL on the fly. It looks like your version doesn't.
From command line it seem's trying to use sudo i686-w64-mingw32-gcc 64 bit compiler and supplying 32 bit DLL i.e. win32/dll/csfml-audio-2.dll. change to x64/dll/csfml-audio-2.dll. It should work fine.
I am trying to compile a windows .c file on linux using the following command:
wine gcc.exe x.c -o x.exe -lws2_32
And I get this error.
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../libmingw32.a(main.o):main.c:(.text+0x104): undefined reference to `WinMain#16'
However, when using gcc.exe with the -shared attribute, the error gone.
wine gcc.exe -shared x.c -o x.exe -lws2_32
I tried viewing the help page of gcc.exe but can not find anything related to "-shared" argument
What does this argument do ?
-shared will make a shared object from the code, rather than an executable.
An executable would need a main function as an entry point, hence the undefined reference error you saw.
The shared object can be linked with other objects to make an executable.
See here or here
You first line is actually almost correct. (Doctorlove told you that shared is for making shared objects, libraries, which is true.)
You have to add:
wine gcc.exe -mwindows x.c -o x.exe -lws2_32
The -mwindows option is to tell GCC that you want to link a graphical Windows program, not a console program. Of course, your program must also contain a main() or WinMain() function, or you will get the same error message again.
As a side note, you may want to know that you don't have to use wine to cross compile with Mingw. There are mingw cross compilers for Linux. On Debian and Ubuntu you install it with apt-get install mingw32.