How to get Eclipse CDT working with WxWidgets under windows? - wxwidgets

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"

Related

How do I build a CMake project?

I have just acquired an arbitrary CMake project from the internet and I am not sure how to compile it. What commands do I need to run to build it from the command line?
Basic steps
If you're on a Unix-y operating system, like Linux or macOS, then you would run:
$ cmake -DCMAKE_BUILD_TYPE=Release -S /path/to/source-dir -B /path/to/build-dir
$ cmake --build /path/to/build-dir
Here, /path/to/source-dir is the directory containing the root-level CMakeLists.txt, this is most commonly the root of a source control repository. Meanwhile, /path/to/build-dir is a distinct directory (that does not need to exist yet) that CMake will use to store the generated build system and its outputs. This is called an out-of-tree build. You should never attempt an in-tree build with CMake because of the possibility of name clashes and difficulty involved with cleaning up the generated files.
When building with a single-config generator (like Make, which is the default on Unix), you specify the build type by setting the CMAKE_BUILD_TYPE variable in the first command, known as the configure step. You must always set this variable when working with a single-config generator. The built-in configs are Debug, Release, RelWithDebInfo, and MinSizeRel. See this answer for more detail on this.
After the configure step, you may build the project by either calling the underlying build tool (in this case, make) or by calling CMake's generic build launcher command (cmake --build), as I do here.
If you're on Windows, then the default generator is Visual Studio, which is a multi-config generator. This means the build type is chosen during the build step rather than the configure step, and the commands must be adjusted accordingly:
$ cmake -S /path/to/source-dir -B /path/to/build-dir
$ cmake --build /path/to/build-dir --config Release
These steps assume that the CMake build you are looking at is well behaved. If a project fails to build with the above steps and you have all of its dependencies installed to system locations (and they are well behaved), then you should open an issue with the upstream project. The most common source of bad behavior in mature CMake builds is dependency handling. Too often you will have to read the build or its documentation to determine which variables need to be set (via -D, like we did with CMAKE_BUILD_TYPE above) for the project to find its dependencies.
Advanced topics
Setting options and cache variables
Some projects offer options to enable/disable tests, components, features, etc. These are typically done by writing entries to the CMake cache during the configure step. For example, a common way to disable building tests is to set BUILD_TESTING to NO at the command line:
$ cmake -S /path/to/source-dir -B /path/to/binary-dir [...] -DBUILD_TESTING=NO
This particular variable is a convention, but is not guaranteed to be honored. Check the project's documentation to see which options are available.
Selecting a generator and toolchain
When using the Visual Studio generators specifically, you can tell CMake which platform you wish to target and which version of the compiler you would like to use. The full form of the CMake configure command for this is:
$ cmake -G "Visual Studio 16 2019" -A <ARCH> -T<TOOLSET> [...]
Valid values of <ARCH> include Win32, x64, ARM, and ARM64. If <TOOLSET> is not specified, then the 32-bit MSVC compiler will be used. Typically, you will want this to be host=x64 to ensure that 64-bit MSVC is used, which can allocate more memory for large linking steps. You can also set <TOOLSET> to ClangCL to use the Visual Studio provided ClangCL tools.
On all generators, CMake sniffs the environment for which compiler to use. It checks the CC and CXX environment variables for the C and C++ compilers, respectively. If those are empty, it will look for cc and c++ executables in the PATH. You can manually override the compilers by setting the CMAKE_C_COMPILER and CMAKE_CXX_COMPILER CMake cache (not environment) variables at the CMake command line (using -D again).
Installing & using dependencies
Once a CMake project has been built, you may install it either systemwide or (preferably) to a local prefix by running:
$ cmake --install /path/to/build-dir --prefix /path/to/install-dir [--config Release]
Where --config is only required if a multi-config generator was used. Once installed to a local prefix, a project that depends on it may be configured by setting CMAKE_PREFIX_PATH to /path/to/install-dir.

Conan does not detect MinGW gcc

Conan does not auto-detect MinGW compiler while creating package. Please refer below error:
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
ERROR: : 'settings.compiler' value not defined
SOLUTION 1
using the conan dev packages you can install msys2 or mingw64.
Conan has setup some bins you can clone via build requires. These work like pre-requisites meaning any machine that uses the conan profile with these will get them installed. This would mean you would get another self container mingw, and msys inside your conan packages (home/.conan/data/ blah blah).
[build_requires]
mingw_installer/1.0#conan/stable
msys2/20190524
[settings]
os_build=Windows
os=Windows
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=4.9
compiler.libcxx=libstdc++11
compiler.threads=posix
build_type=Release
Credits to AvadhanaSolutions
SOLUTION 2
The reason that it is not working is because not only does the toolchain need to be set for gcc,g++ but also the target and generator need to be defined. This needs to be clear to both conan, and cmake. In this case cmake cannot find these toolchains.
Given that the recommended install locations for mingw and msys binaries are to not place in "Program Files". The install location is variable from one person to the next. Given that variability we need to ensure two things to generate successful builds. The following would not only apply for gcc but also for other tools like clang
Steps
Find path for gcc,g++, and make for your machine.
(careful to ensure that you have the full names)
#!/bin/bash
echo "Find Gcc,G++ and mingw make then append these to a conan profile"
which gcc
which g++
which make
Which will return something like
/c/msys64/mingw64/bin/gcc
/c/msys64/mingw64/bin/g++
/c/msys64/usr/bin/make
Add environment variables to the conan install profile.
(ie my conan file has)
[env]
CC=C:/msys64/mingw64/bin/gcc
CXX=C:/msys64/mingw64/bin/g++
Define the Generator for Cmake. Here we need to setup the equivalent to the CMake command cmake .. -G "MinGW Makefiles. By default conan uses Unix Makefiles unless your running windows ;) then it just uses whatever cmake applies as the default generator. Therefore, if you want to use mingw make files that needs to be defined and passed to cmake manually. (found this in the conan documentation here. But note that the conanfile on that page is somewhat incomplete. In the end you have to add other elements from your default conan profile to the conan profile you will be using for building to target the MinGw platform using the mingw toolchain.
toolchain=C:/msys64/mingw64/bin
target_host=x86_64-w64-mingw32
cc_compiler=gcc
cxx_compiler=g++
[env]
CONAN_CMAKE_FIND_ROOT_PATH=$toolchain
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
RANLIB=$target_host-ranlib
CC=$target_host-$cc_compiler
CXX=$target_host-$cxx_compiler
STRIP=$target_host-strip
RC=$target_host-windres
[settings]
#We are cross-building to Window
[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=gcc
build_type=Release
compiler.libcxx=libstdc++11
compiler.cppstd=20
compiler.version=10
[options]
[env]
CC=C:/msys64/mingw64/bin/gcc
CXX=C:/msys64/mingw64/bin/g++
Note that the CC, and CXX toolchain variables are duplicative, but I honestly don't care. I want to tell windows and cmake in as many ways as possible to use those.
In the end, it is probably easiest to think of this as "Cross Compiling" because the default installs of cmake, path variables, and the windows platform is not setup to compile using non-windows compilers. This page (newer) from conan describes how this can be defined on a windows machine. There is a bit of background at the top, but it is helpful to understand the landscape of what is going on between these tools.
In the end... after all of this, I am going to take a look at ninja because it appears that it will improve my quality of life. I am also going to switch to a conanfile.py instead of a conanfile.txt because the documentation is better for these.
The issue can be resolved by updating default profile or create a new profile for MinGW.
Update default profile:
conan profile update settings.compiler=gcc /path/to/profile
conan profile update settings.compiler.version=9.2 /path/to/profile
conan profile update settings.compiler.libcxx=libstdc++11 /path/to/profile
Create new propfile at path .conan/profile/
[build_requires]
mingw_installer/1.0#conan/stable
msys2/20190524
[settings]
os_build=Windows
os=Windows
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=4.9
compiler.libcxx=libstdc++11
compiler.threads=posix
build_type=Release
Note:
You need to add MinGW/bin path in windows environment.
Developer can choose compiler version as per their installation.

How do I compile objective-C in code blocks?

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.

How to build flite test project for windows 8?

I tried the C example in the documentation, but I can't make it work. I am not sure what files do I need in the include and lib directories and how to set the FLITEDIR variable because I am using Windows 8.1 and VS2015. In example:
gcc -Wall -g -o flite_test flite_test.c -I$FLITEDIR/include -L$FLITEDIR/lib -lflite_cmu_us_kal -lflite_usenglish -lflite_cmulex -lflite -lm
I tried
gcc -Wall -g -o flite_test flite_test.c -IE:\flite\include -LE:\flite\lib -lflite_cmu_us_kal -lflite_usenglish -lflite_cmulex -lflite -lm
I built the flite vcxproj for Release and I got an fliteDll.pdb file and some cmu.obj files. I also buit the project for Debug and I got a flite.lib and cst.obj files. I am a beginner programmer. Can you tell me what to do?
gcc is for Linux, you simply need to follow Windows build process:
Create a VS2015 project
Add C code flite_test.c into it
In project properties add include path to flite libraries
In project properties in linker configure linking to flite.lib
Compile VS2015 project and run
For more details see the walkthrough on creating and using DLL libraries in Visual Studio

Building SDL2_image as a CMake external project

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
...