Thread: Compiling with GTK+ / MinGW

Originally Posted by Sotos

...
I assume that all this command does is link the .c files to the GTK+ libraries. Isn't there a way to do this for my compiler instead of having to run the command line every time I want to compile an app?

All decent IDEs let you use 3rd party libraries, by specifying the library's include/ & lib/ directories inside the IDE's project.

But for your own benefit, I would strongly suggest to start learning how to use your compiler from the command line.

By the way, from what I've picked up from the thread, your IDE is CodeLite and your compiler is some variation of mingw. Code::Blocks has been already suggested as a better IDE (dunno really, I only tried CodeLite once, didn't like it and ditched it).

C::B already provides a GTK+ project template, but most probably you'll have to point it to the correct directories of your GTK+ installation. Still, I strongly believe it's better if you first get familiarized with the command-line options of your compiler. This frees you up from any IDE's peculiarities. Put otherwise, it will be a breeze to set up any 3rd party library to any IDE that supports your compiler.

Anyway, here is a GTK+2 replayer I made a while back for a 2048 console clone of mine.

The above link explains how to install GTK+ on Windows, and how to compile GTK+ apps on Windows, either using the native console, or msys. The latter comes with most if not all variations of the mingw toolchain. Contrary to the native console, msys supports backticks in the command line.

I hope it helps. If not, ask

Just create a new "console application" project, and then add your source files into it, at the corresponding window of C::B. That's all about it. Providing you have installed C::B via its "mingw included" installer, you are all set.

PS. For GTK+, it will be a bit different. If my memory serves me well, there is a small error in the GTK+3 project
template of C::B, which you may need to google for fixing it.

Alternatively, if you are already familiar with compiling GTK+ apps from the command-line, you can create a new EMPTY project, and then set it up manually for GTK+.

Migration from CodeLite to Code::Blocks successful. Now, I assume I have to create separate GTK+ files for every project I am planning to use.

EDIT: Managed to link Code::Blocks with GTK+, though, due to some error, I have to use version 2.22 instead of the latest build, 3.something.

You may also have a look at this post (I think it's the error in C:B's GTK+ project template I mentioned in my previous post).

PS. Btw, my suggestion for using the command-line still stands. By now you would have already compiled a few GTK+ sample programs found in tutorials for beginners

Also, you wouldn't rely on C::B's (or any IDEs) project templates, but at the same time you would be able to setup an EMPTY C::B project manually, for any version of GTK. All decent IDEs provide access to the compiler's command line.

Originally Posted by Sotos

The problem is that every tutorial assumes familiarity with the command line

Probably 'cause familiarity with the command-line is pretty much the norm among (at least) the C programmers.

...
Any relevant tutorials from you guys?

It's not that difficult, but different compilers use different command-line options.

With the very popular gcc toolchain (thus mingw too) on Windows (that's your case I think) you can build an executable hello.exe from a source file hello.c by issuing the following command-line:

Code:

gcc hello.c -o hello.exe

If you want to statically link your code against a 3rd party library, first you need to know the directories in which the header and the binary files of the library are stored in your system (.h and .a, respectively).

Lets say the header file of a 3rd-party library called XXX is stored as c:\include\xxx.h, and the static binary is stored as: c:\lib\libxxx.a

In your hello.c file you can use the XXX library's functions, types, etc by first adding: #include "xxx.h".

Then the compiler needs to know where to find the xxx.h header and the libxxx.a binary of the library during compilation. In gcc the relative command-line options are -I and -L, respectively.

So, the command-line becomes:

Code:

gcc hello.c -o hello.exe -Ic:/include -Lc:/lib -lxxx

The last part (the "-lxxx" one) is actually a linker command-line option, specifying the exact binary file to link against, which the compiler will search for, in the dir specified with the -L option... in our example, this would be the file: c:\lib\libxxx.a (in the command-line you OMIT the "lib" and ".a" parts of the filename).

The above examples are simplified, just to get you started (for example gcc is a driver program, that unifies several steps to one, and it provides countless command-line options).

Now, GTK+ actually depends on several libraries, so the command-line for the compilation needs to specify them all using several -I, -L and -l options.

pkg-config is a tool that lists those dependencies, and if your shell supports backticks , then you can embed pkg-config directly into the compilation command-line of your gtk+ app, without needing to write the options explicitly.

However, Window's command-prompt does NOT support backticks, so pkg-config cannot be embed into the compilation command-line. Instead, you run pkg-config as stand alone in the command-line, and it spits out the needed options. You can then copy & paste them into the compilation command-line of your app.

There are more tools available, e.g. make, cmake, etc, but I would advice against trying to learn them all at once. I have already given you a link to the docs of a GTK+2 replayer of mine, where I explain how to compile GTK+2 apps using Window's native console (actually, I show how to define ONCE an environment variable containing the output of pkg-config, and then use that environment variable in the compilation command-line of any GTK+2 app.

In its simplest form it looks something like the following:

Code:

gcc hello.c -o hello.exe %GTK2_COMPILE%

Note that the above is just one way to do things. There are many other alternatives, but I think it's pretty good for getting you started.