Why can't I build a "hello world" for glib?

Question

So here's the world's simplest glib program:

#include <glib.h>

I try to compile it with gcc test.c and I get:

test.c:1:18: error: glib.h: No such file or directory

So I make sure that I have the right packages:

# dpkg -l | grep libglib
ii  libglib-perl                              1:1.183-1                               Perl interface to the GLib and GObject libra
ii  libglib1.2-dev                            1.2.10-19build1                         The GLib library of C routines (development)
ii  libglib1.2ldbl                            1.2.10-19build1                         The GLib library of C routines
ii  libglib2.0-0                              2.20.1-0ubuntu2                         The GLib library of C routines
ii  libglib2.0-cil                            2.12.1-1ubuntu2                         CLI binding for the GLib utility library 2.1
ii  libglib2.0-data                           2.18.2-0ubuntu2                         Common files for GLib library
ii  libglib2.0-dev                            2.20.1-0ubuntu2                         Development files for the GLib library
ii  libglibmm-2.4-1c2a                        2.18.1-1                                C++ wrapper for the GLib toolkit (shared lib

Then I search for any "glib.h" anywhere under /usr/include. I get two, /usr/include/glib-1.2/glib.h and /usr/include/glib-2.0/glib.h. So I try:

$ gcc -I/usr/include/glib-2.0 -Wall test.c  
In file included from /usr/include/glib-2.0/glib/galloca.h:34,
             from /usr/include/glib-2.0/glib.h:32,
             from test.c:2:
/usr/include/glib-2.0/glib/gtypes.h:34:24: error: glibconfig.h: No such file or directory

(about 10,000 more errors snipped)

I don't seem to have a glibconfig.h anywhere on my computer.

What do I do now?

Solution 1

glib tends to hide itself... Your include statement doesn't work because GCC doesn't automatically search subdirectories, and so cannot see the glib.h in glib-1.2 or glib-2.0.

Read the Compiling GLib Applications page in the GLIB manuals... you use commands like pkg-config --cflags glib-2.0 to get the right flags for GCC.

The canonical way to do what you are trying is

% gcc test.c -Wall -o test `pkg-config --cflags --libs glib-2.0`

Note the back-ticks, which tell the shell to run the pkg-config command "in-place".

Solution 2

> > The canonical way to do what you are trying is

> % gcc test.c -Wall -o test `pkg-config --cflags --libs glib-2.0`

Sorry, but no. That is a common misconception, that just happens to work in most cases on ELF-based systems, Linux in particular. The canonical way is to pass in the cflags and libraries separately, in the correct and traditional locations on the command line, like this:

gcc -Wall -o test `pkg-config --cflags glib-2.0` test.c `pkg-config --libs glib-2.0`

It is a pity that pkg-config accepts both the --cflags and --libs options at the same time, as it means this incorrect meme will never die, and people used to it on Linux will continue to be baffled when they then try the same on other platforms.

Solution 3

As @chris said use pkg-config.

glibconfig.h is missing 

it’s because this file is not in the /usr/include/glib-2.0, but in /usr/lib/glib-2.0. So you have to include also this /usr/lib path or copy the file to the /include/glib-2.0

Comments

[GManNickG]

Maybe I'm just being silly, but why are you trying to compile a header?

[mike]

I started with a more complex program, but if "#include <glib.h>" won't work, nothing will.

[Yasushi Shoji]

If you do not have a main function, it will not work. Replacing your glib.h with stdio.h does not work, either. Assuming you have a main function, a right answer is to use pkg-config as mentioned in other answer.

[Keith Thompson]

@YasushiShoji: gcc -c test.c should work just fine if test.c contains just #include <stdio.h>. It wouldn't hurt to add a second line void test(void) { }, but it's not necessary. In the OP's case, the error message would appear regardless of what follows the #include <glib.h>.

[Chris Huang-Leaver]

+1 for bravery! Strictly speaking the name of the source code file should go at the end, after all the options.

[tml]

Sorry, but that is just not true. Have you actually tried doing it that way on some non-Linux platform, for instance MinGW? See for instance gcc.gnu.org/onlinedocs/gcc/Link-Options.html which clearly says "It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o' searches library z' after file foo.o but before bar.o. If bar.o refers to functions in `z', those functions may not be loaded".

[sam1132]

the file is provably there, so a Debian-specific package management command is not going to solve the issue. using pkg-config correctly will.

[ntd]

This is not hiding: glibconfig.h is a list of arch dependent data and so does not pertain to /usr/include. It is commonly found under /usr/lib/glib2/...

[ALM]

would you mind putting the " ` " in your code. that had me confused for sometime. granted its my fault for not reading your the rest of your answer, but the code snippet as it is now is inaccurate.