glibconfig.h is required to compile a program using glib.h. All other glib.h include files are in /usr/include/glib-2.0. glibconfig.h is in /usr/lib/glib-2.0/include The url points to some discussion on the subject, which I won't repeat. I've used a symlink to get things compiling. My POV is that it is dumb. No include files under lib!!!!! > pkg-config --variable=includedir glib-2.0 /usr/include pkg-config --cflags glib-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
`pkg-config --variable=includedir glib-2.0` alone won't give you the correct path as you need to append "glib-2.0" to it. I guess the rationale behind this is : - /usr/include/glib-2.0 has all the includes that are system/arch independant - /usr/lib64/glib-2.0/include has the #defines that are system/arch dependant GLib has been doing this for _years_, if you don't like it, talk to upstream. I, for one, will not change this without a _very_ good reason. None of the arguments on the KDE mailing list are particularly convincing, in my opinion. Thanks
> ls /usr/lib/*/include/ there is a bunch of gnome packages in there with one file each but see xulrunner, firefox, ... are also doing it. Like remi said I don't see the point in "fixing" this bug which is a non issue with pkg-config (and you really should use pkg-config anyway). If you really want this fixed, please talk to upstream.
I still think putting include files under /usr/lib is mad, but as you say, its all upstream. They must have a reason. I hope. Thanks for your time. --john
There are certain headers that *must* be in /usr/lib: those that are arch specific. A multilib system, for example, needs some different headers for 32-bit and 64-bit, and that can't be done in /usr/include. Those go in /usr/lib[64]/
