Cross-compiling c++ with sdl on linux - c++

I'm on Arch Linux, and I have a C++ SDL2 program, contained in single main.cpp file, and I compile it for Linux with such command:
g++ main.cpp -lSDL2 -lSDL2_image
Now I wanna compile it for windows. Any advice on what should I do?

I suggest my own tool, quasi-msys2, which lets you reuse the precompiled SDL2 for MinGW provided by MSYS2 (and more).
Install Clang, LLD, make, wget, tar, zstd, gpg.
git clone https://github.com/HolyBlackCat/quasi-msys2
cd quasi-msys2/
make install _gcc _SDL2 _SDL2_image
env/shell.sh
win-clang++ main.cpp `pkg-config --cflags --libs sdl2 SDL2_image`
This should produce a.exe, which you can test using wine a.exe (or just ./a.exe, after running env/shell.sh).
How to do this manually:
For completeness, SDL2 itself distributes precompiled binaries for MinGW, meaning the manual setup is not hard. Any tutorial for MinGW should work.
Install MinGW from your package manager.
Download and unpack SDL2-devel-??-mingw.zip and SDL2_image-devel-??-mingw.zip.
Specify the paths to the directories with .a files using -L... and to .h files using -I.... Add -lmingw32 -lmingw32 -mwindows -lSDL2main -lSDL2 -lSDL2_image to the linker flags.
Follow this troubleshooting guide if you get stuck.

I'd go for cmake really.. SDL2 ships with a CMakeLists.txt and it's as simple as running this from your build folder.
cmake.exe ..
cmake.exe --build .
EDIT: if you want to cross-compile, you need MinGW and the addition of the mingw flags to the cmake generator
cmake \
-D CMAKE_C_COMPILER=/path/to/wingw/gcc \
-D CMAKE_CXX_COMPILER=/path/to/mingw/g++ \
-G "MinGW Makefiles" ..

Related

Cpp including SDL library with GCC

Im currently trying to compile a cpp program with gcc that uses SDL2 library, and im using Ubuntu 20.04 LTS. Here is my folder structure
project
-out
-SDL2
-src
-main.cpp
Excluding the library i have uploaded everything to this repo https://github.com/probottpric/libtest if it gives a better understanding.
To install SDL2, I installed source code and ran ./configure and make all. I dont want to run make install which installs it on /usr/*. I want the library to be on the local folder.
To compile program im using this command
gcc -o ./out/main ./src/main.cpp -ISDL2 -lSDL2 -lSDL2main -lm -std=c++11
But It shows library not found error. What am i doing wrong ?

Is there a way to link SFML libraries in VSCode Mac?

Is there a reasonably easy to follow way to link SFML libraries with VSCode in macOS?
My case:
Using Mac
Using Clang with VSCode
Have Xcode installed
Am an amateur
Note : I am using clang and Mac
See my question and answer here: Manually link and compile C++ program with SFML (macOS)
In a nutshell:
download sfml for mac
copy include directory from extracted folder to your project directory
copy the dynamic library files to your project also, folder lib
in terminal type the g++ command and link to the dynamic libs
It will be something like this:
g++ main.cpp -o main -I include -L lib -l sfml-system -l sfml-window -l sfml-graphics -l sfml-audio -l sfml-network -Wl,-rpath ./lib
here's a boiler plate to link sfml in vs code:
https://github.com/andrew-r-king/sfml-vscode-boilerplate
If you have Macbook M1, the other answers won't work. The reason is because sfml from the website is compiled in x86_64, and you can't compile the libraries directly to arm64. So, you need sfml and pkg-config to be installed on Homebrew.
Command:
g++ main.cpp $(pkg-config --libs --cflags sfml-window sfml-system sfml-graphics) -o main
More detailed solution here: https://stackoverflow.com/a/53510642/16264548
If you don't wan to use pkg-config, then you can manually type in the locations:
main.cpp -I/opt/homebrew/Cellar/sfml/2.5.1_1/include -L/opt/homebrew/Cellar/sfml/2.5.1_1/lib -lsfml-window -lsfml-system -lsfml-graphics -o main
To enable the editor features, you can add library include files to C/C++ configurations:
Open Command Palette (⇧⌘P by default)
Type and select "C/C++: Edit Configurations (UI)"
In section "Include path" add a line: /your/path/to/sfml/include/*
In my case, the path is /usr/local/Cellar/sfml/2.5.1_1/include/*

How to link statically to wxWidgets from Kdevelop on linux?

Hello I have installed wxWidget-3.1.0 s on windows it works fine using it from MSVC++. But On Linux fedora 27 I built it in a sub-directory "wxWidget3.1.0/build-gtk-unicode-release".
These are the comands:
../configure --disable-debug
make
sudo make install
sudo ldconfig
Above it generates for me a release shared library I get around building programs upon it. So I easily use "wx-config --cxxflags --libs". For Ides like Eclipse, Codeblocks, Kdevelop.
The problem is I need some "static version" of the library so I created another sub-directory: "wxWidgets-3.1.0/build-gtk-static-release-unicode" So I issued the commands:
../configure --disable-debug --disable-shared --enable-unicode
make
sudo make install
I created a project with Codeblocks and it compiles easily with adding only "wx-config --cxxflags --libs"
When it comes to Eclipse CDT I used wx-config --cxxflags for the compiler and wx-config --libs for the linker. But it fails complaining
about "Unreferenced defeinition of the APIs".
After a long search I Find a tricky workaround:
Project->Properties->C/C++->GCC C++ Linker->Experts settings:
${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
So I made the "Flags" at the end to become:
${COMMAND} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS} ${FLAGS}
And it works fine.
*** The problem:
I'd like to configure Kdevelop for wxWidgets as a static library keep in mind as a dynamic library I managed to do that. So My Configurations are:
From Kdevelop->Project->Open Configuration->CMake File->CXX_COMPILER_FLAGS I enters:
The result of wx-config --cxxflags in a terminal.
And for the linker:
CXX_LNKER_FLAGS:
The reult of wx-config --libs
But The code compiles but doesn't build I don't have "expert settings" as in Eclipse CDT.
Can anyone solve how to link to wxWidgets from Kdevelop statically?
Thank you for this boring long story. NB: I Added What problems I faced and what did to get around them to help people who face the same problems. Thank you in advance.

Can't use static lib of mongo-cxx-driver on Linux

So I follow the official tutorial for the installation : https://mongodb.github.io/mongo-cxx-driver/mongocxx-v3/installation/
Neverless, I can't use the produced libraries as static.
So I managed to compile the C version of the driver as described, I've enabled the flag --enable-static=yes with the ./configure before doing make && sudo make install and I got the libmongoc-1.0.a and the libbson-1.0.a which are static. So this far, everything it's alright.
Then I have done the cxx version of the driver, except that there is no configuration file as in the C version. So I've juste done a
cmake -DCMAKE_BUILD_TYPE=Release -DBSONCXX_POLY_USE_BOOST=1 -DCMAKE_INSTALL_PREFIX=/usr/local
from the build folder, followed by a make && sudo make install
So I got the libmongocxx.a and the libbsoncxx.a, but when I try to compile with them, I can't run the binary because I got the following error :
error while loading shared libraries: libmongocxx.so._noabi: cannot open shared object file: No such file or directory
So I understand that is because there is some symbols missing and then I need to use the shared library to run the binary but I don't want this to happend, I want the symbols within the binary that I can run it without any LD_PRELOAD.
Any suggestions ?
I had the same issue in an Ubuntu 16.04 and I run a apt-get update & apt-get upgrade and the problem was solved.
It seems that there were some update to the compiler and some libraries that prevent some test from reaching the shared libraries.
I have a similar question, and solved, now I compiled and run my binary with static libs successfully.
I write my build script using newlisp, but the static link options are very helpful, I paste it here.
c++ /to/your/path/site/code/back_end/builder/object/files1.cc.o ... /to/your/path/site/code/back_end/builder/object/files10.cc.o -o bin/site -static-libgcc -static-libstdc++ -L/usr/lib -lpthread -l:libmongocxx.a -l:libbsoncxx.a -l:libmongoc-1.0.a -l:libbson-1.0.a -lrt -lssl -lcrypto -lsasl2 -l:libboost_log.a -l:libboost_log_setup.a -l:libboost_system.a -l:libboost_thread.a -l:libboost_filesystem.a -lcppcms -lbooster -lcurl -ljsoncpp

trouble installing old 2005 BOOST library

Gooday everyone
I'm fairly new to ubuntu C programing although I'm
rather experienced in C programing in windows.
I have recently come accross a number of codes written
in 2005 which I'm interested in learning how they work.
Those codes needs BOOST library to compile, however they won't
compile on the newest BOOST version present on my ubuntu 12.04.
I set the gcc compiler on lenient so that it ignores all those error
messages. The code did compile and ran afterwards.
However, when I used GDB debugger to watch how the program flows
I noticed that there are likely errors in the way the program runs
due to using a different BOOST version rather than it's original. Hence
I like to install the BOOST version corresponding to the code I downloaded.
To do that, I installed Ubuntu 5.04 and BOOST 1.33.0 which seemed to have been created in late 2005. I downloaded it
but I didnt found any detailed instruction on how to install it.
Only vague description on using BOOST jam, I played around with BOOST
jam for quite awhile without success.
And this old BOOST does not have installation commands like
"sudo apt-install boost-dev" style option
Thus I like to ask if anyone can give a easy to understand step by step instruction
on how to install the BOOST library downloaded from the above link.
like.....
step1: download boost jam from boost webpage
step2: unpack it in home/boost/ then type make configure
...and so on...
Big thanks for any useful info.
New Contents appended here
in response to the comments given
Hi, I went through the info given by your link and
managed to run the boost library examples given by your link.
That is, I can compile a single cpp file with the command
g++ -I boost_1_33_0 test.cpp -o test
(I'm keeping the boost library and the cpp file to be compiled in the
same folder)
However, the program package I'm interested in is build with make (not cmake).
I have some experience writting cmake files but not make files.
And I do not see any link to boost library command in the make file of the
program package. The readme file only has one sentence that says I
need to have boost installed without explaining what that meant.
I assume it means that either I have to build and do makeinstall the boost or
I could add some lines in the makefile for a link. I thought
maybe you can quickly point out whats missing in the makefile.
The readme file:
To compile, go into the moses directory and do 'make'. You'll need the
latest boost libraries. If compilation still fails for weird reasons,
you could try g++ with the -fpermissive (newer versions reject lots of
code that was ok with older ones). If you are going to be making
changes and recompiling frequently you'll probably want to disable -O3
in the makefile (I use templates liberally, so -O3 really speeds up
the code, but really slows down compilation).
And the makefile:
CC = g++
PROJ_NAME = moses
LINK_FLAGS = -Wall -Iutils/ -Itrees/ -Irewrite -I./ -Imodeling/ -Ifitness/ \
-Ialignment/ -Isim/ -Ilocal/ -O3
COMP_FLAGS = -Wall -Wno-sign-compare -Iutils/ -Itrees/ -Irewrite -I./ \
-Imodeling/ -Ifitness/ -Ialignment/ -Isim/ -Ilocal/ -O3
src := $(wildcard *.cc) $(wildcard utils/*.cc) $(wildcard trees/*.cc) $(wildcard modeling/*.cc) $(wildcard fitness/*.cc) $(wildcard alignment/*.cc) $(wildcard main/*.cc) $(wildcard rewrite/*.cc) $(wildcard sim/*.cc) $(wildcard local/*.cc)
obj := $(patsubst %.cc,%.o,$(src))
all: $(PROJ_NAME)
%.o: %.cc
$(CC) $(COMP_FLAGS) $< -c -o $#
$(PROJ_NAME): $(obj)
$(CC) $(LINK_FLAGS) $^ -o $(PROJ_NAME)
run:
$(PROJ_NAME)
clean:
find -regex ".*~\|.*\.o"|xargs rm -f
rm -f $(PROJ_NAME)
rm -f $(PROJ_NAME).exe*
depend:
makedepend -Y -- $(COMP_FLAGS) -- $(src)
utils/exceptions.o: utils/exceptions.h utils/utils.h
utils/io_util.o: utils/io_util.h utils/tree.h utils/basic_types.h
# ......lots more lines like that.........
I have an old instruction flying around here for Boost 1.34.1, which reads like this (project-specific stuff cut away):
unpack boost sources
cd into tools/jam/src
run ./build.sh to build bjam
cd into the main source directory
tools/jam/src/bin.linux/bjam threading=multi --layout=system --toolset=gcc --without-python variant=release --prefix=/usr/local install
The --without-python was necessary as the target system didn't have Python installed, which caused the build to fail messily.
Obviously you can / need to fiddle with the individual settings (like threading support, release vs. debug variant) to suit your needs, but it should be a good starting point.
If you need ICU support (for Boost.Regex and Boost.Locale), it gets more complicated...
Note that the build process has changed over the years; you shouldn't use the same procedure for more up-to-date boost versions. It's just what I used back then.
Edit:
As for the second part of your question, the Makefile doesn't need to refer to Boost explicitly if boost is installed in the standard system directories.
You do not have to state -I /usr/include for compilation as that is searched automatically; the same goes for -L /usr/lib during linkage.
The fact that the author of the Makefile copied the compiler flags into the linker flags verbatim doesn't really help intuitivity either... ;-)
If you have Boost in a custom directory (either the headers only, or by stating a custom directory in the --prefix option of my build instructions), you need to make the following modifications (look for "boost"):
LINK_FLAGS = -Wall -Iutils/ -Itrees/ -Irewrite -I./ -Imodeling/ -Ifitness/ \
-Ialignment/ -Isim/ -Ilocal/ -L /path/to/boost/libs -O3
COMP_FLAGS = -Wall -Wno-sign-compare -Iutils/ -Itrees/ -Irewrite -I./ \
-Imodeling/ -Ifitness/ -Ialignment/ -Isim/ -Ilocal/ \
-I /path/to/boost/includes -O3
That should do the trick. As the Makefile does not link any of the Boost binaries (e.g. -l boost_program_options or somesuch), it seems that it makes use of the Boost headers only, which would make the -L /path/to/boost/libs part (and, actually, the whole compilation step detailed above) superfluous. You should be able to get away with simply unpacking the sources and giving the header directory as additional include directory using -I /path/to/boost/headers.