I recently had to install the latest gtk for a piece of software which basically broke my system. (Because of all the dependencies and conflicts) I've gotten X working finally but there's a lot of gnome programs that segmentation fault upon running, I'm trying to fix that, I assume they need updated gnome libraries. So I'm looking for gdk stuff...

I try to install the latest gdk-pixmap and it can't find glib, gtk, pango, or cairo. (Hint: I have the latest versions of all these compiled and installed.) And I've had this problem before and gone in and changed the configure script but I'm sick of it.

How is pkg-config supposed to work? And why does the latest version of pkg-config have a directory for glib-1.2.8. And why is none of this stuff kept in sync? And why do I have glibconfig.h and gdkconfig.h files in library directories, installed, by default by the latest version of gtk.

And most of all, how do I fix it all? How do I get configure to find the libraries and includes it needs and where are those libraries and includes supposed to be for glib/gtk/cairo/pango/atk.

I'm thinking I should just write a script that appends -I and -L and -l with paths to all these things and just stuff it in CFLAGS and LDFLAGS whenever I have to compile one of these things. But, oh wait, that's what pkg-config is supposed to do.

I guess its free so I can't complain.

The most easy way to upgrade such libraries is through your package manager. If you prefer the hard way (i.e. compiling from sources) then you must be careful about the installation location. If you installed your libraries in /usr (using ./configure --prefix=/usr) then everything should be OK. If not, then you must append to your PKG_CONFIG_PATH the directory to the newly installed libraries (where the *.pc files are):
before compiling software that depends on these libs

I generally let compiled from source libraries/etc. install where they want to since I presume that the default is where libraries dependent on them will expect them. pkg-config's /usr/local/lib/pkg-config generally has all the .pc files that I presume it needs.

Perhaps this is a related error, but I'm getting:

Gdk-CRITICAL **: gdk_window_set_title: assertion `title != NULL` failed

for a lot of gnome related apps, basically anything that uses gtk or gdk before I upgraded the libraries. I figure I have to recompile every single application that uses gdk or gtk since I upgraded gtk but perhaps this isn't necessary somehow? I've googled this error, and there's a sparsity of information about it. It seems that it does occur but no one says specifically why it occurs. The closest I got was someone who compiled a simple 20 line app using gdk and gtk that segmented with this error on gtk_init, I think.

I think I'm going to go see if there are any gtk tests in the source folder I can run.

So I'm trying to narrow down this gtk/glib bug that comes up in everything that uses those libraries. If I run tests/simple in the gtk source, it crashes with the same errors.

So gtk_init gets called and that calls some other things and eventually its supposed to set the name of the program which becomes the title of the program with g_set_prgname. This is called from g_option_context_parse. Both of these last two functions are in the glib source, not the gtk source.

Now at first I thought maybe it was some funky thread magic that I just don't understand but on second thought, maybe its a bug. g_option_context_parse calls g_set_prgname on the first argument passed to the application on the command line, i.e. the name of the binary. Then it frees that.

g_set_prgname frees the passed prgname after setting g_prgname equal to the program name. But a later call to g_get_prgname returns NULL.

I have no idea what's killing that g_prgname. Is it some thread thing, is it some mismatched library that there's two different copies of glib in memory and g_prgname is being overwritten? I don't get it.

This is i think where your logic is falling short.
default installs /usr/local is the default for developer testing purposes.
developers can install with default path and know their core installation in /usr will never get overwritten. You have to remember a gnome or gtk developer will be runing one version while constantly testing and compiling over and over again a newer version.

so what you have created is a situation where you have not "upgraded" anything but rather are trying to run multiple versions of everything at the same time. this is a situation not for the uninitiated.
it is doable clearly because the developers do it but it requires a full understanding of the behaviour of linking and runtime library lookup paths etc.

next -- it is often simply not obvious or even possible to be able to compile "all the latest" and get the system up and running. often even for a very experienced Linux builder the complexities of especially Gnome and all its dependant but seperately developed packages prove an imposible task. Often for instance one package is ahead on some change and thier latest package is meant to work with future other packages
etc. Gnome has the added complexity of all its configuration in /etc and you need to decide exactly where everything is on your current instalation and where you want everything with what you are doing now.
defaults aren't going to do it you are going to have to take controll.

as far a pkg-config is concerned it only for instance looks for a file labled glib-2.0.pc
the first one it finds it goes with. every version of glib just installs a glib-2.0.pc file.
if you have a bunch of those on you system you have to take controll over which one you are using.
from man pkg-config
By default, pkg-config looks in the directory pre-
fix/lib/pkgconfig for these files; it will also look in the colon-separated (on Windows, semicolon-
separated) list of directories specified by the PKG_CONFIG_PATH environment variable.

I posted an email to the gtk-list at gnome in the hope that someone would know what was up with all this so maybe I'll hear back from that.

All the software I got was stable versions, not cvs checkouts so there should be no problem with one package being developed for features past another.

Furthermore, I've compiled most of the software on all my *nix systems from source and the most trouble I've had with library problems is either a compilation not finding a library/correct version, or an undefined reference. Compiled programs with unrelated errors due to a library conflict is strange.

pkg-config I think is finding everything properly but a particular program I was compiling called glib-config which I assume is deprecated. I also (have to double check on this) have a gtkconfig.h and I think a glibconfig.h in directories separate from the include directories for these two packages.

But the main problem are these persistent Gdk, gtk, glib errors that occur in a good number of the programs compiled with them. I didn't do anything radically different here. And with that g_prgname variable that is allocated and then retrieved later as NULL, I can only assume that gtk has some block allocated for, in this case, application variables and the g_object_new call to allocate memory for g_prgname allocates a block that's larger than gtk expects and then maybe gtk copies it...

I'm guessing here, but the point is that there's a very specific problem here, I have a very tiny piece of code tests/simple.c, that illustrates it, and I have a huge number of applications compiled under different circumstances that do and do not work and that should be enough to figure out what the problem is. At the very least, it seems like poor design in gtk and glib. Either data structures should be properly encapsulated and accessed within their respective libraries, or version information should be checked in situations where things like this can break. This is like a pointer got lost between two libraries and I need to at least figure out which two.

Has anyone seen something like this before? Does this happen often? There's a lot of errors of these types on google, totally unexplained, but I think most people just clear it out and let the package management system take care of it. Does anyone have suggestions for narrowing down the problem?

I just can't believe that this is rare or that no one has fixed this before who wasn't developing for gnome in a sanitary development environment.

when you built GTK (and glib and friends) did you do
./configure --prefix=/usr (plus other options)

debian installs GTK in /usr and the default for ./configure is to install in /usr/local

this can be a huge pain in the ass when dealing with gtk/gdk-pixbuf/glib