Based on this question I was able to make one default cmake compilation for GLFW libraries, compile my GLFW App and run; everything works and was made through the terminal since I'm using Ubuntu 14.04 64 bits.
I was using this line to compile:
g++ -std=c++11 -c main.cpp
And this to link:
g++ main.o -o main.exec -lGL -lGLU -lglfw3 -lX11 -lXxf86vm -lXrandr -lpthread -lXi
After use those commands I only needed to execute main.exec. However, I would like to setup eclipse to compile and run this GLFW application. Include files are already settled on the project but I'm having trouble with my linkers. I was trying to track my libraries (GL, GLU, glfw3....) manually to set the folders but I couldn't find all of them. Does anyone know how could I track the libraries to set them on my linker(Project - Properties - C/C++ Build - Settings - GCC C++ Linker) or could give me some guidelines to solve this situation, please?
Thanks in advance
After try and research for some hours, I found the solution which is pretty easy:
Instead of add paths to libraries, just add their names as it is in the command line. I still don't know from where the path reference for those libraries are coming (and would be great if someone could explain) but what is most important is that works. After build just run (CTRL + F11) like any other application.
Related
I can already cross-compile some simple applications using x86_64-w64-mingw32-g++. However, I cannot find out how to find libraries for my project (in my case I need to use SDL2 and SDL2_image). I know how to install these libraries already (sudo apt install libsdl2-dev libsdl2-image-dev), but apt search does not show any libraries for x86_64-w640mingw32-g++.
Here are the links I've looked at:
https://arrayfire.com/cross-compile-to-windows-from-linux/
https://stackoverflow.com/questions/2033997/how-to-compile-for-windows-on-linux-with-gcc-g
Is there a way to use precompiled libraries, or do I need to add the source code in my project?
Update: I followed the instructions advised by Laurent Jospin, and can compile a "Hello World" program that works with Windows (I sent it to a friend to test). However, I cannot compile my program that uses SDL.
Terminal output:
$ /opt/mxe/usr/bin/x86_64-w64-mingw32.shared-g++ -O3 main.o Game.o TextureManager2D.o Map.o Entity.o Player.o -mwindows -lSDL2 -lSDL2_image -o ../../../endeavour-client.exe
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.shared/5.5.0/../../../../x86_64-w64-mingw32.shared/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o): In function `main':
/opt/mxe/tmp-gcc-x86_64-w64-mingw32.shared/gcc-5.5.0.build_.crt/../gcc-5.5.0.build_/mingw-w64-v8.0.0/mingw-w64-crt/crt/crt0_c.c:18: undefined reference to `WinMain'
collect2: error: ld returned 1 exit status
$
Changing -mwindows to -municode, -d UNICODE, -Wl,-subsystem,windows, or removing it all do not work.
What you are looking for is the M Cross Environnement: https://mxe.cc/
It is a set of makefiles able to download and cross compile a selection of popular libraries for windows on linux. By default it builds static libraries, such that you ends up with .a libraries that get merged into the final .exe, meaning you don't have to worry about shipping the dlls with your app. But if you prefer a modular structure, it can also builds some dlls.
The list of libraries they do provide is quite impressive. If a library is missing on the other hand you can still install it by copying the corresponding header files and dlls. In some specific situation you might have to cross-compile one of your dependency (I had to do that for an app using ruby scripting. The official windows build of ruby is somehow incompatible with certain libraries built with mingw. But this is rather exceptional).
The correct command is:
$ /opt/mxe/usr/bin/x86_64-w64-mingw32.shared-g++ -O3 main.o Game.o TextureManager2D.o Map.o Entity.o Player.o -mwindows -lmingw32 -lSDl2main -lSDL2 -lSDL2_image -o ../../../endeavour-client.exe
Edit: Note that having -lmingw32 -lSDL2main -lSDL2 -lSDL2_image in that exact order is vital.
I, being the absolute idiot that I am, forgot to include the -lmingw32 AND -lSDL2main flags in the command, which is why there is the issue with WinMain not being found. When using MinGW-w64 as the cross compiler, the -lmingw32 library has to be included. And of course, SDL requires the -lSDl2main flag when building for windows (but interestingly enough, not on Linux). Here are the links I used. (I had an uncommon insight in replacing -lSDLmain with -lSDL2main, as the links are pretty old.)
MinGW Starter Guide
Code::Blocks Forums
SO: Undefined Reference to WinMain
I'm trying to compile a program i made using SDL2 to work on others computers (or testing VM in this case).
I've been compiling it with what i think are the correct flags, e.g. g++ main.cpp -o main -lSDL2, however when i try executing it on another Ubuntu installation i get this error.
error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
From my understanding it's not a problem in my compiling but with how i expect it to work on another Linux installation; I've cross-compiled (using mingw32) and tested it (using a freshly installed VM) on Windows adding the correct dlls with the exe (seems to work fine) and I was expecting for it to work in a similar fashion.
What's the standard in this cases? Should i write a setup scripts to install the library dependencies on the target machine? Is there another way I'm not aware of? I've never released an application for Linux (nor Windows) and I'm struggling to find the resources to do things "the right way".
Thanks for everyone suggestions, I ended up settling for the easy way, compiling the "easy to install" libraries dynamically e.g.-lSDL2 and the others statically (checked the licenses and it should be fine) like so:
g++ main.cpp -o main -Wl,-Bdynamic -lSDL2 -lSDL2_image -lSDL2_ttf -Wl,-Bstatic -lSDL2_gfx -static-libgcc -static-libstdc++
I'll put in my documentation how to install the required SDL2 libraries.
I am not sure how familiar you are with pkg-config, but the output for sdl2 is this:
-D_REENTRANT -I/usr/include/SDL2 -lSDL2
This was found from running this:
pkg-config --cflags --libs sdl2
Basically, you need to point to where SDL2 is located BEFORE you actually link to it.
The tool pkg-config is designed to tell you the information you need when you want to link to a package in Linux. You were linking with the library, but you forgot to tell GCC where the library is located.
If you want to compile you code, try this:
g++ main.cpp -o runme `pkg-config --cflags --libs sdl2`
This will automatically grab all of the flags that you need to compile with SDL2 included.
Oh, and you should note, ORDER MATTERS WHEN ADDING FLAGS AND LIBRARIES!!!
There are many questions on SO where the order of compiler options caused all of the problems. Do not be like those people. I suggest you search SO for more info on that.
I'm creating a game in c++ with the Panda3D framework on Ubuntu. All of the Panda3D shared libraries are in /usr/lib/panda3d and all of the headers are in /usr/include/panda3d. I'm compiling with SCons, but I've tried it with gcc and it's the same, so here are the commands:
g++ -o src/main.o -c -fPIC -O2 -std=gnu++11 -I/usr/include/python2.7 -I/usr/include/panda3d -Iinclude src/main.cpp
g++ -o Test src/main.o -L/usr/lib/panda3d -lp3framework -lpanda -lpandafx -lpandaexpress -lpandabullet -lp3dtoolconfig -lp3dtool -lp3direct -lpthread
And here is the error I get when I run the executable:
./Test: error while loading shared libraries: libp3framework.so.1.11: cannot open shared object file: No such file or directory
There isn't much in the code, just initializing a Panda3D window, so I doubt that's the culprit.
As I said before, the libraries are in /usr/lib/panda3d, I've checked about a million times now and it's driving me crazy. I can't think of a single reason why I would get this error. Any help is appreciated :)
Edit:
I was looking through my files and there's a panda3d.conf file in /etc/ld.so.conf.d with one line: /usr/local/lib/x86_64-linux-gnu/panda3d. Does this have anything to do with it?
Edit #2:
I used the path in the above edit as the library path and got the same results, unfortunately.
I can't think of a single reason why I would get this error.
The reason is very simple: the dynamic loader hasn't been told to look in /usr/lib/panda3d for shared libraries, and so doesn't.
You can run your program with:
LD_DEBUG=files,libs ./Test
and observe which directories the loader is searching.
panda3d.conf ... with one line: /usr/local/lib/x86_64-linux-gnu/panda3d
That is the wrong directory (or at least not the one where your libraries are).
One way to fix this is to correct the above path to /usr/lib/panda3d and run sudo ldconfig.
Another way is to add -Wl,-rpath=/usr/lib/panda3d to your link line.
I'm working on a project on a Raspberry Pi 2 Model B. I started coding and compiling directly on the Pi and now I want to work on a Windows 7 PC. I already installed the SysGCC Cross-Compiler and managed to compile a simple Hello-World program.
Problem is, for my Project i use curl and jsoncpp. Natively on the Raspberry i have no problems compiling it, but the cross-compiler on Windows gives me following error:
c:/sysgcc/raspberry/bin/../lib/gcc/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lcurl
c:/sysgcc/raspberry/bin/../lib/gcc/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -ljsoncpp
I don't use a makefile or so because i never really worked with that and on the raspi it just worked fine with this command:
g++ ../src/rpi/main.cpp ../src/rpi/connection.cpp ../src/rpi/jsonparser.cpp ../src/rpi/idchecker.cpp ../src/rpi/eventoperator.cpp -o ../bin/main -lcurl -ljsoncpp
On the Windows system i tried it with a command like this:
arm-linux-gnueabihf-g++.exe -std=c++11 ../src/rpi/main.cpp ../src/rpi/connection.cpp ../src/rpi/jsonparser.cpp ../src/rpi/idchecker.cpp ../src/rpi/eventoperator.cpp -o ../bin/main -L"C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/usr/include/jsoncpp/json/" -L"C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/usr/include/arm-linux-gnueabihf/curl/" -lcurl -ljsoncpp
So i read that i have to tell the compiler/linker where the libraries are, but i don't really understand why since it works perfectly without the -L flag on the Raspi. I think i put the libraries in the same folder as on the Raspi, so i don't understand why they are not found. I hope someone can help me ore give me some short basic explanation on how this stuff works, cause i don't find any working tutorial or other helpful questions for my problem.
On raspberry-pi the libraries are most likely to be linked from system directory like /usr/lib or /usr/local/lib. On Windows, you need to specify the correct path(s) with -L flag.
There is a small project C++ (it has win32 code) that I need to build. It already has its Makefile. I was told to use MinGW. I have never used it before. I downloaded and installed the latest MinGW installer.
Then, I opened the MinGW shell and did make. The exe file was created. But when I try to run it I get libgcc_s_dw2-1.dll is missing! Why do I get this error? Shouldn't the exe be self-contained and run anywhere?
UPDATE
Here's more information, from the Makefile:
CC = g++
CCOPTIONS=-DWINDOWS -DFORCEINLINE -DMINGW -DSRTP_SUPPORT -D__EXPORT= -D_WIN32_WINNT=0x0501 -DNOMVS
setup.exe: setup.o common.o
$(CC) -ggdb -g -O0 -o $# setup.o common.o -mno-cygwin -mwindows -lwsock32 -lws2_32 -lwinmm -lgdi32 -lcomctl32 -lmapi32 -lVfw32
Whether or not the exe should be self-contained depends on how you built it. We need to see the commands that were executed, or post the makefile. But that DLL does not seem to be part of the current version of MinGW. Also, please clarify if you are actually doing this under cygwin, or if you added the tag by mistake.
Edit: A bit of googling seems like it has to do with the horrible "official" MinGW installation. Remove it, and download the Twilight Dragon build from http://tdm-gcc.tdragon.net and then rebuild completely. The "official" build is cr*p anyway - I don't know why anyone uses it.
If what you want to do is a stand alone application with MinGW, you should add -static to the linking options.
On a side note, if you're making a Win32 application, add the -mwindows option to the C++ compiler so it doesn't open a console together with your main window.