wxwidget compiling on windows command prompt - c++

Can someone please guide me on the method,as to how I would compile wxwidget using windows command prompt or MSYS. [I can't seem to find anything on the wxwiki/wxwidget official book/anywhere else]
I have already compiled wxwidget from the instructions they have provided (using MSYS).
From searching on the Internet it seems one can (maybe?) do it through the use of MAKEFILE (is that correct?)
if yes: WHAT directory & HOW I should link the wx libraries in the MAKEFILE
if no: what is the way besides MAKEFILE?
I know I can use IDE's like code::block and make life simpler but I prefer to compile using the command prompt/msys.
Thanks in advance.

I have created a video on this topic https://www.youtube.com/watch?v=f6FDNR3lh8E
Here is small and simple steps to follow.
Pre-Requirements :
GNU g++ compiler downloaded and installed.
Set gcc/g++ path to Enviroment Variable.
Download WxWidgets Binaries : 1. Header Files, 2. Development Files, 3. DLLs.
Extract then one folder as it is. I have extracted them at D:\WxAPI Folder.
Looks Like :
D:
- WxAPI Folder
- include (Header files has this folder ziped in .7z)
- lib (Development Files & DLL has this folder ziped in .7z and both extracts in this save folder)
Set your project development structure.
My Project Development Structure :
WxExample (Project Folder)
- Build (Folder) : Contains debug and release dlls and exe
- debug (Folder) : Contains debug specific dlls and exe.
- release (Folder) : Contains release specific dlls and exe.
- inlcude (Folder) : Contains project header files.
- src (Folder) : Contains project .cpp files.
- wxCompiler.cmd : Contains compile command created with following steps.
Write Compilation Command
Link Following to Compile.
First Compile Project *.cpp Files :
g++ ".\src*.cpp"
Give Project Output .exe Name :
-o ".\build\release\Project_Name.exe"
Show Project .h File Location to g++ :
-I ".\include"
Provide WxWidget .h Files :
-I "D:\WxAPI\include"
Locate WxWidget setup.h File :
-I "D:\WxAPI\lib\gcc810_x64_dll\mswu"
Supply Binaries Location of WxWidgets :
-L "D:\WxAPI\lib\gcc810_x64_dll"
Provide Compile Flags :
-l wxbase31u
-l wxmsw31u_core
Here D:\WxAPI\lib\gcc810_x64_dll\libwxbase31u.a File Renamed To "wxbase31u"
& D:\WxAPI\lib\gcc810_x64_dll\libwxmsw31u_core.a File Renamed To "wxmsw31u_core" as flag.
You have to add similar file flag as you used in your project as .h
For Example :
-lwxmsw31u_core -lwxbase31u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lshlwapi -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lversion -lwsock32 -lwininet -loleacc -luxtheme
Here is Full Command :
g++ ".\src*.cpp" -o ".\build\release" -I "D:\WxExample\include" -I "D:\WxAPI\include" -I "D:\WxAPI\lib\gcc810_x64_dll\mswu" -L "D:\WxAPI\lib\gcc810_x64_dll" -l wxbase31u -l wxmsw31u_core
Run wxWidgets.cmd and that's it. Your exe is in your .\Build\release folder.
Set WxWidget DLL path in Enviroment Variable.
If you do not want to copy paste required dll to your release/debug folder.

Related

How to link libraries with g++ compiler?

I'm trying to link a game library for my game project in C++. I am using the g++ compiler and Atom Code Editor. Also on a Windows machine.
To link the library it needs to link those things:
Include path
Library path
Additional dependencies
The main.cpp file is at ProjectRoot/src/main.cpp and the library is at ProjectRoot/deps/lib_name
Inside the library there is and include folder, with the .h file for including, and a lib folder, with the .lib file. It's a static linking library.
So far, I've tried the following commands:
g++ -o ExecutableName.exe -I /deps/lib_name/include -L /deps/lib_name/lib src/main.cpp
Well, that didn't work though... It said that there was no such file or directory as library_name.h...
I need to know if I'm doing anything wrong and also how to specify the additional dependencies.
Every thing is correct . You just forgot to link the libraries . Do it as follows -
g++ -o ExecutableName.exe -I /deps/lib_name/include -L /deps/lib_name/lib src/main -l[library name] -l[library name]

Build Qt static from source enabling OpenSSL support

I followed the instructions for the Qt static build as described in https://wiki.qt.io/Building_a_static_Qt_for_Windows_using_MinGW. Running the script on my Windows 10 machine just works fine and builds Qt statically. However, since I require OpenSSL support I can not compile my program with the static build produced from the .psscript.
Therefore, I slightly changed the configure.bat options of the .ps script from -no-openssl to
-openssl-linked
-I C:\OpenSSL-Win32\include
-L C:\OpenSSL-Win32\lib\VC\static
OPENSSL_LIBS="-lUser32 -lAdvapi32 -lGdi32 -lCrypt32"
OPENSSL_LIBS_DEBUG=-"lssleay32MTd -llibeay32MTd"
OPENSSL_LIBS_RELEASE="-lssleay32MT -llibeay32MT
to enable OpenSSL support in a static Qt build, based on the anwseres from:
QT https SSL support for static QT static program build - getting 'Protocol "https" is unknown'
and
Is there any way to building static Qt with static OpenSSL?
Running the script now produces not further specified errors in the make install steps. The -lUser32 -lAdvapi32 -lGdi32 -lCrypt32 libs are not in any subfolder of my OpenSSL-Win32 installation but can be found in C:\Windows\System32\.
I interpret the question as:
How can I build Qt static from source enabling OpenSSL support at the
project installation target?
One of possible ways is:
Static Qt build: configure -static -debug-and-release -openssl -I %OPENSSL_HOME%\include -L %OPENSSL_HOME% and more options
Link the project executable with same SSL at %OPENSSL_HOME%
Distribute the corresponding libeay32.dll and ssleay32.dll altogether with the rest of executables

Library Locations - Linux

I have an SFML application I would like to compile it for Windows from Linux. Up until now, I've compiled with g++ and -lsmfl-graphics -lsfml-window -lsfml-system
Now I've installed g++-mingw-w64-x86-64 and I have to compile with '/usr/bin/x86_64-w64-mingw32-g++'
Now it says SFML/.../...hpp: No such file or directory
I read that I need to give it the location of the .so files of the library.
I've never seen those, where are those typically? SFML is installed in /usr/local/include/SFML
-L'/location???'
L'/usr/lib/x86_64-linux-gnu'
L provides the search directory where the .so files are located.
The SFML .so files just happen to be in /usr/lib/x86_64-linux-gnu
Then you use your library flags normally
-lsfml-...
-I: path to header file *.h, *.hpp (i upper)
-L: path to library (*.so *.a)
-l: library name (L lower)
g++ -I /path/to/header -lmylib -L /path/to/library
Now it says SFML/.../...hpp: No such file or directory
compile error because header file not found. fix it first.

How to build and load shared library on rstudio for package that uses C/C++ files in src folder inside a subdirectory?

I have a R package that I'm working on that contains code written in C and C++ under the src folder. Currently, the package compiles and works on Rstudio as it follows the default directory structure. As the project builds, I want to be able to organize my code under src, within subfolders. Following directions from "Writing R extensions" - Compiling under sub-directories, I have made a folder called 'test'(/src/test) which now contains all my files(*.c, *.cpp, *.h) and modified my Makevars like so -
SOURCES_C = $(wildcard test/*.c)
SOURCES_CPP = $(wildcard test/*.cpp)
PKG_CPPFLAGS= -I${R_HOME}/include -I.
PKG_LIBS = -L${R_HOME}/lib
CXX_STD = CXX11
OBJECTS =$(SOURCES_CPP:.cpp=.o) $(SOURCES_C:.c=.o)
all : $(SHLIB)
#PKG_CFLAGS= -Wall
clean : rm -f *.o
I want to be able to compile the program in this state, where the C/C++ files are under subfolders inside src. Using the aforementioned Makevars -> the separate object files are being built from the test folder with the correct flags and compiler, for all C/CPP files. However, there are some discrepancies with the build command for the shared object. This is the log when compiling the files under src/test which fails with an undefined symbol error.
gcc -std=gnu99 -shared -L/usr/local/lib64 -o BioCro.so test/BBox.o test/Climate.o test/Compound.o test/Grid.o test/LeafOptics.o test/Maths.o test/Normal.o test/Point3D.o test/Ray.o test/Triangle.o test/Vector3D.o test/runFastTracer.o test/Assigncropcent.o test/AuxBioCro.o test/AuxCropGro.o test/AuxMaizeGro.o test/AuxcaneGro.o test/Auxcropcent.o test/AuxwillowGro.o test/BioCro.o test/CalculateBiogeochem.o test/Calculate_Soil_Layer_Temperature.o test/CanA.o test/CanAC_3D.o test/Century.o test/Copy_CropCent_To_DayCent_Structure.o test/Copy_SoilWater_BioCro_To_CropCent.o test/CropGro.o test/CropGro_c.o test/Filling_BioCro_SoilStructure.o test/assignManagement.o test/c3CanA.o test/c3EvapoTrans.o test/c3photo.o test/c4photo.o test/caneGro.o test/createNULLc3tree.o test/cropcent.o test/dailywillow.o test/denitrify.o test/diffusiv.o test/eC4photo.o test/getIdirIdiff.o test/getsoilprop.o test/leachdly.o test/maizeGro.o test/methane.o test/microclimate_for_3Dcanopy.o test/nitrify.o test/nox_pulse.o test/pi_funcs.o test/printcropcentoutput.o test/test_mainC.o test/tgmodel.o test/tracegas.o test/update_3Dcanopy_structure.o test/wfps.o test/willowCent.o test/willowGro.o -L/usr/local/R-3.1.0/lib64/R/lib -L/usr/local/R-3.1.0/lib64/R/lib -lR
installing to /home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/
** R
** data
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/libs/BioCro.so':
/home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/libs/BioCro.so:
undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE
Error: loading failed
Compared with the successful log which builds successfully!
g++ -shared -L/usr/local/lib64 -o BioCro.so Assigncropcent.o AuxBioCro.o AuxCropGro.o AuxMaizeGro.o AuxcaneGro.o Auxcropcent.o AuxwillowGro.o BBox.o BioCro.o CalculateBiogeochem.o Calculate_Soil_Layer_Temperature.o CanA.o CanAC_3D.o Century.o Climate.o Compound.o Copy_CropCent_To_DayCent_Structure.o Copy_SoilWater_BioCro_To_CropCent.o CropGro.o CropGro_c.o Filling_BioCro_SoilStructure.o Grid.o LeafOptics.o Maths.o Normal.o Point3D.o Ray.o Triangle.o Vector3D.o assignManagement.o c3CanA.o c3EvapoTrans.o c3photo.o c4photo.o caneGro.o createNULLc3tree.o cropcent.o dailywillow.o denitrify.o diffusiv.o eC4photo.o getIdirIdiff.o getsoilprop.o leachdly.o maizeGro.o methane.o microclimate_for_3Dcanopy.o nitrify.o nox_pulse.o pi_funcs.o printcropcentoutput.o runFastTracer.o test_mainC.o tgmodel.o tracegas.o update_3Dcanopy_structure.o wfps.o willowCent.o willowGro.o -L/usr/local/R-3.1.0/lib64/R/lib -lR
installing to /home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/libs
1) The shared object compiles using g++ under default conditions, whereas under subdirectory conditions the compiler used is gcc. Can I change that behaviour via Makevars?
2) Further research allowed me to find that the undefined symbol error is a linking error fixed by the -L/-l flag. However, the -L flag is the same for both build commands. Is there any other library I am failing to link which is linked by default?
I ran into the same issue. Looking at the example of the RSiena package mentioned as an example in "Writing R Extensions" section 1.2.1.3 I noticed that that package still has some .cpp files not in a subdirectory. So I added a dummy.cpp file in src/ with the following contents:
void dummy (void)
{
}
After this g++ was correctly used for the linking step and the .so file was created as expected.
In my case it turns out that I don't need to change the Makevars files as I first mentioned in my answer. Even without the change below (so only having the dummy.cpp file present in src/) linking is done correctly.
I'll leave it in in case it may help someone else with a (slightly) different setup.
And add the corresponding .o file in the list of $(OBJECTS) variable in the Makevars file:
OBJECTS = $(SOURCES:.cpp=.o) dummy.o

Static-linking of SDL2 libraries

I am using Windows 7, Code::Blocks and MinGW. I have little to no experience when it comes to compiling/building anything, especially when Code::Blocks doesn't use makefiles.
I downloaded SDL2-devel-2.0.0-mingw.tar.gz (SDL Development Libraries) from http://www.libsdl.org/tmp/download-2.0.php, and I'd like to create a standalone executable using SDL2 libraries, but so far I've always had to bundle the SDL2.dll file with the executable to make it work.
I've heard that I can not static-link dynamic libraries, so my only option seems to be doing something with the source files using the file SDL2-2.0.0.tar.gz (Source Code) from the link I mentioned above. However, I do not know what I should do with those.
What I managed to try with the source files is importing the Visual Studio project to Code::Blocks and building it, but it tells me "sdl-config No such file or directory" (I do not know what triggered that). I'm also not sure if building merely gives me an executable, with which I do not know what I can do to link it to my own executable.
A fool proof idiot's step by step guide would be the best bet to solve this case.
EDIT:
I managed to compile the SDL libraries with the guide Jonas provided, and got a libSDL2.a file.
At first I only added the path of libSDL2.a to "Link libraries:" -section of Code::Blocks, but I got a bunch of errors such as "SDL_Init() not declared in this scope".
In addition to the libSDL2.a path, I also added the path of SDL2-2.0.0\include to the Compiler's search directory as well as the path of SDL2-2.0.0\build.libs to the Linker's search directory. I also wrote this to my test file: #include "SDL.h". My test file now looks like this:
#include "SDL.h"
int main( int argc, char* args[] ) {
//Start SDL
SDL_Init( SDL_INIT_EVERYTHING );
//Quit SDL
SDL_Quit();
return 0;
}
It appears it did fix the declaration problem, but now Code::Blocks opened a SDL_mmjoystick.c file and gave me even more errors: "undefined reference to 'waveInClose#4'", "undefined reference to 'waveOutClose#4'", "undefined reference to 'joyGetNumDevs#0'" and tons of other ones.
Here's a screenshot of what's happening, note the different color of #include texts, I'm not sure why that happens: http://gyazo.com/00656a9c1e57a2bd0db1414fa7d68ced.png
I am not sure how to correctly take this library into use. Any help in this case, or should I make another question for it?
EDIT:
I added -lSDL2 to the linker options and deleted the other parameters. Now it builds fine:
mingw32-g++.exe -Wall -fexceptions -g -IC:\Users\User\Desktop\SDL2-2.0.0\include -c "C:\Users\User\Desktop\CppProjects\SDL project\main.cpp" -o obj\Debug\main.o
mingw32-g++.exe -Wall -fexceptions -g -IC:\Users\User\Desktop\SDL2-2.0.0\include -c "C:\Users\User\Desktop\CppProjects\SDL project\thetestfile.cpp" -o obj\Debug\thetestfile.o
mingw32-g++.exe -LC:\Users\User\Desktop\SDL2-2.0.0\build\.libs -o "bin\Debug\SDL project.exe" obj\Debug\main.o obj\Debug\thetestfile.o -lSDL2 ..\..\SDL2-2.0.0\build\.libs\libSDL2.a C:\Users\User\Desktop\SDL2-2.0.0\build\.libs\libSDL2.a -mwindows
Output size is 945.80 KB
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings (0 minutes, 1 seconds)
But when I try to run it, it says my computer lacks SDL2.dll, while the whole point was to static-link.
So currently I have the path to build/.libs in my Link libraries -settings, -lSDL2 in the Other linker options, and for search directories I have the path to SDL2-2.0.0/include for the compiler and SDL2-2.0.0/build/.libs for the linker.
In the build/.libs directory I can also see libSDL2.a, libSDL2.dll.a, libSDL2.la and libSDL2.lai files, which I don't know what they are.
It's not necessary to recompile the library,
SDL2 is given with static-link library named "libSDL2.a"
on the folder "SDL2-2.0.0\i686-w64-mingw32\lib\".
Just be sure to add these options to the linker :
"-lmingw32 -lSDL2main -lSDL2 -mwindows -lm -ldinput8 -ldxguid -ldxerr8 -luser32 -lgdi32 -lwinmm -limm32 -lole32 -loleaut32 -lshell32 -lversion -luuid -static-libgcc"
on Code:Blocks at "Project / Build Options... / Linket settings / Other linker options"
These options allow you to link with what SDL2.dll was using.
You can retreive them on the file "SDL2-2.0.0\i686-w64-mingw32\bin\sdl2-config"
The magical trick is to delete or rename the file "libSDL2.dll.a"
on the folder "SDL2-2.0.0\i686-w64-mingw32\lib\".
I added a "-" before to keep it in case I need it.
I don't know why this librairy overcomes the other and a clue would be appreciated.
I tried with Code::Blocks 12.11 MinGW32 and it worked.
If you run with some projects that use dynamic-link
and some other which use static-link, you will have to
keep your librairies in two different folders knowing that
"libSDL2main.a" will be in those two.
Sorry for my writing, I'm not used to write in english.
Mike