wxWidgets-3.1.3
Eclipse IDE 4.14.0
Eclipse CDT 9.10.0.2019x (the latest packages as of 2/2/2020)
MinGW compiler, installed via MSYS2
Windows 10 Pro
I have been using Eclipse for years for PHP, Python, JavaScript, and lua. I am, however, new to C++ and Eclipse CDT. I've got a reasonable enough grip on C++ syntax and convention that I'm ready to move on to the reason I came to C++, which is GUI. At first I tried Code::Blocks, which seemed simpler (I like wizards!), but I really would prefer an IDE with git integration, and I realised C::B didn't have that before I managed to get compilation working. So, back to Eclipse.
So far, I have done the following:
added the MinGW compiler path to %PATH%
successfully compiled wxWidgets 3.1.3 using SHARED=0 UNICODE=1 MONOLITHIC=0 BUILD=release, these changes made in %WXDIR%\build\msw\config.gcc. The various tutorials I have found wildly disagree on these parameters, but the various responses to people with my problem here and on other forums have all been generally in agreement on them, and with the exception of BUILD, they're the defaults. So.
successfully compiled a test program from samples/minimal. The resulting executable runs without needing any other DLLs in the same directory.
Unfortunately, this is where I'm stuck. There are plenty of tutorials and forum posts out there, but I run into one or more of the following problems:
Not newbie accessible. "Add a link to your wxWidgets directory" but okay, how do I do that, and do you mean the main %WXDIR% code directory or %WXDIR%\lib or what?
Don't work. "Just File->Import->File System->%WXDIR%" and nope. Did, in fact, get rid of the "not resolved" for SOME references in code pasted from "minimal.cpp", but not all.
Explicitly refer to versions of the IDE or Code from, oh, say, ten years ago, and/or contain instructions that cannot be followed in the current version.
Alternately, I would take a recommendation for another GUI toolkit that has accessible instructions for getting the current version of itself working with the current version of Eclipse.
I'll show how to compile the wxWidgets minimal sample with MinGW and eclipse. First of all, I highly recommend that you build both a debug and a release version of the wxWidgets library. These directions will assume that is the case. I'm not an expert with eclipse, so I can't guarantee these are the best directions. These directions do work for me, but corrections and improvements are welcome.
There are many, many steps here. But if you get a working project with the minimal sample, you can copy the project and change the code files to use it for further projects.
Before we do anything else, define the WXWIN environment variable in eclipse if it not already defined. From the menu select Window->Preferences->C/C++->Build->Environment, and the press the add button to add the variable.
The easiest way to build the minimal sample that comes with the library is with the command line. To do this, simply change to the WXWIN\samples\minimal folder and enter the exact same command you used to build the library. Since the command given above was mingw32-make -f makefile.gcc SHARED=0 UNICODE=1 MONOLITHIC=0 BUILD=release, this will result if the following commands being executed in the shell:
windres --use-temp-file -i../../samples/sample.rc -ogcc_mswu\minimal_sample_rc.o --define __WXMSW__ --define NDEBUG --define _UNICODE --include-dir .\..\..\lib\gcc_lib\mswu --include-dir ./../../include --include-dir . --include-dir ./../../samples --define NOPCH
g++ -c -o gcc_mswu\minimal_minimal.o -O2 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DNDEBUG -D_UNICODE -I.\..\..\lib\gcc_lib\mswu -I.\..\..\include -W -Wall -I. -I.\..\..\samples -DNOPCH -Wno-ctor-dtor-privacy -MTgcc_mswu\minimal_minimal.o -MFgcc_mswu\minimal_minimal.o.d -MD -MP minimal.cpp
g++ -o gcc_mswu\minimal.exe #gcc_mswu\minimal.exe.rsp -mthreads -L.\..\..\lib\gcc_lib -Wl,--subsystem,windows -mwindows -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
If we do the same command with build=debug instead we get similar commands with just a few differences:
windres --use-temp-file -i../../samples/sample.rc -ogcc_mswud\minimal_sample_rc.o --define __WXMSW__ --define _UNICODE --include-dir .\..\..\lib\gcc_lib\mswud --include-dir ./../../include --include-dir . --include-dir ./../../samples --define NOPCH
g++ -c -o gcc_mswud\minimal_minimal.o -g -O0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE -I.\..\..\lib\gcc_lib\mswud -I.\..\..\include -W -Wall -I. -I.\..\..\samples -DNOPCH -Wno-ctor-dtor-privacy -MTgcc_mswud\minimal_minimal.o -MFgcc_mswud\minimal_minimal.o.d -MD -MP minimal.cpp
g++ -o gcc_mswud\minimal.exe #gcc_mswud\minimal.exe.rsp -g -mthreads -L.\..\..\lib\gcc_lib -Wl,--subsystem,windows -mwindows -lwxmsw31ud_core -lwxbase31ud -lwxtiffd -lwxjpegd -lwxpngd -lwxzlibd -lwxregexud -lwxexpatd -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lshlwapi -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lversion -lwsock32 -lwininet -loleacc -luxtheme
To build the sample with eclipse, we want to make it execute roughly the same commands accounting for the slight differences between the debug and release configuratins. Select File->New->C/C++ project->C++ Managed Build. Enter a project name, select MinGW GCC, make sure the project type is Executable/Empty project, and click the finish button.
Now add a file to the project. You can either
Selecting File->New->Source File, enter a name for the file such as "minimal.cpp" or whatever you want to call it, and hit finish. The new file will automatically open in eclipse. Select and delete the entire contents. In a text editor, open the file WXWIN\samples\minimal\minimal.cpp, select and copy the entire contents, paste into the file just created in eclipse, and save the file.
File->Import->General->File System. Click the next button. Then select the \samples\minimal for the directory. Then select the file minimal.cpp from the list of files this brings up. Finally hit the finish button.
Either way, there should now be a file named minimal.cpp in the project. To build this file, several settings need to be changed. From the menu, select Project->Properties->C/C++ Build->Settings
For GCC C++ Compiler:
For Preprocessor,
for all configurations add __WXMSW__, _UNICODE, HAVE_W32API_H, and NOPCH.
for the release configuration add NDEBUG
For Includes
for all configurations, add ${WXWIN}\include
for the debug configuration, add ${WXWIN}\lib\gcc_lib\mswud
for the release configuration add ${WXWIN}\lib\gcc_lib\mswu
For Optimization
for the release configuration select Optimize more (-O2)
For Debugging
for the debug configuration select Debug level Default (-g)
For Miscellaneous
for all configurations, add -mthreads -W -Wno-ctor-dtor-privacy at the end of the "Other flags" box.
For MinGW C++ Linker:
For Libraries,
for the debug configuration:
for Libraries, add
wxmsw31ud_core, wxbase31ud, wxtiffd, wxjpegd, wxpngd, wxzlibd, wxregexud, and wxexpatd
for the release configuration:
for Libraries, add all of the following: wxmsw31u_core, wxbase31u, wxtiff, wxjpeg, wxpng, wxzlib, wxregexu, and wxexpat
for all configurations
for Libraries, add all of the following: kernel32, user32, gdi32, comdlg32, winspool, winmm, shell32, shlwapi, comctl32, ole32, oleaut32, uuid, rpcrt4, advapi32, version, wsock32, wininet, oleacc, and uxtheme.
for Library search path, add ${WXWIN}\lib\gcc_lib
note: with MinGW the order of libraries is sometimes important and the libraries with names starting with "wx" used with the debug and release configurations should be listed first. You can use the up and down arrows to rearrange the order if necessary.
For Miscelanious,
for all configurations
for liker flags, add -mthreads -mwindows
for Other options (-Xlinker), add --subsystem=windows.
for the debug configuration,
for liker flags, add -g to the existing contents.
Both the debug and release configurations will now build, but the application isn't complete quite yet. The first thing done building the minimal application in the command prompt was
windres --use-temp-file ...
According to this link, eclipse just doesn't support building resource files, so we need to handle this manually.
Copy the files WXWIN\samples\sample.rc and WXWIN\samples\sample.ico into the project folder. (The project folder is the folder containing the minimal.cpp file created earlier). Alternately, you can use File->Import-> ... to import the files into the project.
Now go back Project->Properties->C/C++ Build->Settings->Build Steps.
For Pre-build steps
for the debug configuration, enter windres --use-temp-file -i"${ProjDirPath}/sample.rc" -o"${CWD}\minimal_sample_rc.o" --define __WXMSW__ --define _UNICODE --include-dir ${WXWIN}\lib\gcc_lib\mswud --include-dir ${WXWIN}\include --define NOPCH
for the release configuration enter windres --use-temp-file -i"${ProjDirPath}\sample.rc" -o${CWD}\minimal_sample_rc.o --define __WXMSW__ --define NDEBUG --define _UNICODE --include-dir ${WXWIN}\lib\gcc_lib\mswu --include-dir ${WXWIN}\include --define NOPCH
Next switch back to the Tool Settings tab:
For MinGW C++ Linker:
For Miscellaneous,
for all configurations
for Other objects, add ${CWD}\minimal_sample_rc.o
These 2 extra steps will make eclipse compile the resource file and link the resources into the final executable.
So you start with a brand new project for C++.
Then you add the source code for minimal sample there.
Next you open the project properties you open "C++ Build" -> "Settings" and under "C++ Compiler"->"Directories", you add all your include directories.
Then you go to "C++ Linker"->"Libraries" and add the libraries and a path to them.
Let us know if you still have problems?
Very helpful! Also works for the DLL version with library path ${WXWIN}\lib\gcc_dll instead of ${WXWIN}\lib\gcc_lib .
For a standalone executable, one might extract required DLLs from the vxWidgets library. A minimum post-build step for this is ...
DEBUG:
cmd.exe /Cfor %i in (wxmsw313ud_core wxbase313ud) do xcopy /D /Y "${WXWIN}\lib\gcc_dll\\%i_gcc_custom.dll"
RELEASE:
cmd.exe /Cfor %i in (wxmsw313u_core wxbase313u) do xcopy /D /Y "${WXWIN}\lib\gcc_dll\\%i_gcc_custom.dll"
I am using Header Only Libraries. The libraries are included through Cmake. I am using the g++ Compiler.
Now what I am looking for is to compile the c++ source files via windows cmd. In this moment i am using clion to compile.
Does anyone know how to compile the source files?
If i am compiling the files without cmake , I am getting errors because the program cannot find the libraries.
You do not run a source file, you run an executable produced by a compiler from source file(s)
If you are under a Linux for instance enter the path(s) where the libraries are through the environment variable LD_LIBRARY_PATH
[edit after your remark]
I mean compile
To indicate to g++ where the library are to link use the option -L followed by the path of a directory where the libraries are. If your libraries are on different directories use several time the option, one per directory
I downloaded Codeblocks bundled with GCC from here
The C part is running fine
I read this wiki tutorial which says having GCC will allow me to compile objective C by just adding -lobjc to the compiler options
However, I have followed the steps mentioned in this tutorial and added the -lobjc option, but it doesn't compile
This is the build error message I get in codeblocks:
-------------- Build: Debug in test_prog_proj (compiler: GNU GCC Obj-C Compiler)---------------
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o
mingw32-gcc.exe: error: CreateProcess: No such file or directory
Process terminated with status 1 (0 minute(s), 2 second(s))
1 error(s), 0 warning(s) (0 minute(s), 2 second(s))
As shown above, it does not show the -lobjc option
I have also tried manually compiling the above program in Windows cmd by going into the folder containing the .m file. I gave the following command:
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o -lobjc
But I get the same error in cmd
mingw32-gcc.exe: error: CreateProcess: No such file or directory
I also tried
gcc -g -fgnu-runtime -O -c some_class.m
that I got from here, but it gives me the same CreateProcess error. How do I start compiling Objective C code in Windows (preferably using GCC and Codeblocks) ?
--- EDIT 1 ---
I did as suggested in Mike Kinghan's answer below, and uninstalled my older Codeblocks instgallation, then reinstalled MinGW and codeblocks separately. The Codeblocks uninstall removed the Codeblocks folder in Program Files, but when I reinstalled Codeblocks again (version without MinGW bundled together), the "GNU GCC Obj-C" settings I made with the previous installation was still there, along with the -lobjc flag in the "linker settings" tab.
However, the problem is that it's still not working. I get the following error if I try to build from Codeblocks
Goto "Settings->Compiler...->Global compiler settings->GNU GCC Obj-C Compiler->Toolchain executables" and fix the compiler's setup.
Tried to run compiler executable 'C:\Program Files\CodeBlocks\MinGW/bin/mingw32-gcc.exe', but failed!
Skipping... Nothing to be done (all items are up-to-date).
This is what Toolchains executable looks like:
If I try to compile it from cmd by going in to the folder with the .m file and issuing the command
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o -lobjc
it gives the error
mingw32-gcc.exe: error: CreateProcess: No such file or directory
What is the problem here?
--- EDIT 2 ---
Following the suggestion in Mike Kinghan's answer I deleted the old instance of "GNU GCC Obj-C Compiler" in the list of compiliers, and recreated with the current version of "GNU GCC Compiler"
However, the program still does not work. This is the message I get in the build log:
-------------- Build: Debug in test_prog_proj (compiler: GNU GCC Obj-C Compiler)---------------
Linking stage skipped (build target has no object files to link)
Nothing to be done (all items are up-to-date).
Cleaning the project and then building it again gives the same message. Trying to run the project anyway gives me a dialog box saying the project is not built, and clicking on Yes to build the project just pops the same "project not built yet" dialog box up again. The file icons in the Workspace tree of the Projects tab also seem to be grayed out:
This is what Toolchain Executable looks like:
I have added -lobjc in Linker Settings as mentioned here as well.
I right clicked the project icon in the Project tree, went to Build Options and added -lobjc in the Linker Settings as well:
What is the problem with this project at the moment?
--- EDIT 3 ---
I ended up completely uninstalling Codeblocks (uninstall from windows start menu, delete codeblocks folder in %APPDATA%), uninstalling MinGW (deleting the c:\MinGW folder) and reinstalling everything from scratch. I followed all the instructions in the Wiki (except the Troubleshooting section, but I think that part is irrelevant) and it still doesn't work (same problem as described in Edit 2 in this post).
How do I get Codeblocks to detect and compile obj-C code? Also, it is not showing me the compiler command line arguments when I try to build it from the Codeblocks interface. Why is this and how can I get it to show me whatever the full command line it is using?
The GCC program we loosely call the "the compiler" - [mingw32-](gcc|g++) -
is actually a compiler/linker frontend that invokes a real language
compiler and/or linker depending on what the input files and commandline options
indicate you want it to do.
Input files with an .m extension indicate they are Objective C source files
that are to be compiled with the GNU Objective C compiler, cc1obj. But you
haven't got it. Hence the failure you see.
A GCC installation will include the C compiler cc1 and, optionally, compilers
for other languages - C++, Fortran, Objective (C|C++), Go ... You say you got your MinGW GCC installation as
bundled with Code::Blocks. That bundled MinGW omits the Objective C compiler, cc1obj , because the maintainers
reckon it a niche language.
Best remove your CB installation and bundled MinGW and then install MinGW GCC independently from
one of the rival projects:-
https://sourceforge.net/projects/mingw-w64/
https://sourceforge.net/projects/mingw/
Run the installer and ensure that you get Objective C as well as any other compilers you
want.
After that, replace your CB installation it with the codeblocks-17.12-setup.exe installer (not codeblocks-17.12mingw-setup.exe),
from https://sourceforge.net/projects/codeblocks/files/Binaries/17.12/Windows/. This installer includes no compilers and
will auto-detect your MinGW installation.
Then proceed as you already did to create a GNU GCC Obj-C compiler setup in the CB IDE.
Later ... still not working
Your GNU GCC Obj-C compiler-setup has persisted from your previous
CB install and has been rendered out-of-date by the fact that your
new MinGW installation is no longer part of Code::Blocks. As you see,
it still looks for the toolchain executables in C:\Program Files\Codeblocks\MinGW,
whereas your new MinGW is somewhere else.
When you reinstalled Code::Blocks you should have seen its attempt to auto-detect compilers,
and that it detected your MinGW toolchain in (say) C:\MinGW. It will have configured
a compiler setup for GNU GCC Compiler on that basis, with the correct path to
the toolchain executables. But it will not have modified any persisting compiler setups that
you created yourself, such as GNU GCC Obj-C.
First check that the auto-detected setup GNU GCC Compiler is good just
by creating a "Hello world" C console project and seeing that you can build it.
I assume you'll be able to, but if not, then go into the GNU GCC Compiler setup
yourself and manually set the Compiler's installation directory correctly.
Then, set the same Compiler's installation directory for your GNU GCC Obj-C
compiler setup.
I'm building a dll to use PocoNetSSL to get some data via an HTTPS endpoint. I need to call that dll via C# in Unity which runs an old version of Mono.
I am using mingw-w64 shell to build my dll. There is a package of the Poco libraries available via the package manager pacman and I am using that.
$ pacman -Qs 'poco'
local/mingw-w64-x86_64-poco 1.6.0-2
POrtable COmponents C++ Libraries (mingw-w64)
I can build an executable and it builds fine & runs fine hitting the https endpoint. I have openssl installed somewhere or it may have come with mingw.
My problem is that I cannot open the dll with LoadLibrary. I get a null pointer and I'm guessing it's a dependency problem. Here's my build commands and a snapshot of dependency walker. Is there anything I am missing here. I think I should be able to do this but maybe not?
sburke#sburke-pc MINGW64 ~/sandbox/hitaws
$ scons
scons: Reading SConscript files ...
msys
scons: done reading SConscript files.
scons: Building targets ...
g++ -o gdoaws.os -c -Wall -DPOCO_WIN32_UTF8 -I/mingw64/include gdoaws.cpp
g++ -o gdoaws.dll -Wl,-no-undefined -shared -Wl,--out-implib=libgdoaws.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive gdoaws.os -Wl,--no-whole-archive -L/mingw64/lib -lPocoNetSSL.dll -lPocoNet.dll -lPocoUtil.dll -lPocoFoundation.dll
scons: done building targets.
Assuming your loading a dynamic library code is correct your app is very likely trying to load different version of openssl dlls than Poco was built against.
In msys2 you can check a dynamic library dependencies by:
ldd /mingw64/bin/libPocoNetSSL.dll
which depends on:
LIBEAY32.dll => /mingw64/bin/LIBEAY32.dll
SSLEAY32.dll => /mingw64/bin/SSLEAY32.dll
Is this what you see in dependency walker?
The best workround for this problem is to copy above dlls to the folder where your executable is and always distribute them with your software.
I've been trying to create a CMake-based build-system for a project that is supposed to use SDL2_image library. I do not want to force user to install any libraries to the system to be able to build the project, so I took advantage of the CMake's ability to download and build dependencies (freetype, SDL2 and SDL2_image) from source code as External Projects.
Everything is fine with freetype and SDL2 (which both include CMakeLists.txt files out of the box), but I've ran out of ideas how to make it work for SDL2_image. CMake's external projects support custom configuration and building settings which I used in different variants with no success.
The CMake file itself can be found here, but the problematic part is this:
# SDL_image library
ExternalProject_Add(sdl2_image_project
URL https://www.libsdl.org/projects/SDL_image/release/SDL2_image-2.0.0.tar.gz
DEPENDS sdl2_project
PREFIX ${LIBS_DIR}/SDL2_image
CONFIGURE_COMMAND LDFLAGS=-L${SDL2_BIN} CFLAGS=-I${SDL2_SRC}/include SDL2_CONFIG=${SDL2_BIN}/sdl2-config <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --enable-shared=no
BUILD_COMMAND make
INSTALL_COMMAND ""
)
An error occurs while building sdl2_image_project. Some trivial research discovered that the error is generated by the undefined references to parts of libdl. Here is a tiny part of the hole error:
libtool: link: gcc -I/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project/include -I/usr/local/include/SDL2 -D_REENTRANT -o showimage showimage.o -Wl,-rpath -Wl,/usr/local/lib -pthread -L/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project-build ./.libs/libSDL2_image.a -L/usr/local/lib -lSDL2 -pthread
/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project-build/libSDL2.a(SDL_dynapi.c.o): In function `get_sdlapi_entry':
/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project/src/dynapi/SDL_dynapi.c:227: undefined reference to `dlopen'
I think the problem takes place due to the fact that linker tries to create a shared version of SDL2_image library while linking it to a static libSDL2.a. The thing is - if this is right - SDL2 building step creates both static and shared versions of itself so one would assume that linker would use libSDL2-2.0.so instead (I do not actually need a shared library - just the static one, but I do not know how to prevent the build system from trying to create it apart from passing --enable-shared=no to SDL2_image configure script, which does not help in this case).
After a lot of googling I've discovered that the possible source of the problem is that sdl2-config (which is called to get some flags for compiler during SDL_image building) may be called with wrong arguments and produces wrong cflags which confuse everything else. But I'm not sure that is the case and also I do not know how to influence sdl2_config call from CMake (configure --help does not seem to unveil any useful options for this situation).
I am running Ubuntu 14.04 x64 if it matters in any way. Would appreciate any advice!
Looks like you need to link some libraries like m and dl. It can be fixed by providing
custom sdl2-config file. Copy sdl2-config from extracted archive and substitute --libs result:
--libs)
echo -L${exec_prefix}/lib -Wl,-rpath,${libdir} -pthread -lSDL2 -lm -ldl
;;
Note that order is important (that's why just modifying LIBS not works for me).
Now this file can be used in your ExternalProject_Add command instead of SDL2_CONFIG=${SDL2_BIN}/sdl2-config:
...
... CFLAGS=-I${SDL2_SRC}/include SDL2_CONFIG=${CMAKE_CURRENT_LIST_DIR}/sdl2-config <SOURCE_DIR>/configure
...