Answer #1, a.k.a "Safe Distro Answer": Uninstall glib1 and friends using your package manager. Install glib2 and friends using the same method. Make sure you cp -a all the glib, atk, pango, and g?k .so libs into a safe place first should your package manager decide to whack installed shared libraries. This way you can still run old binaries compiled against glib1 (but you'll not be able to compile any more glib1 stuff.)
Answer #2, a.k.a "By hand". glib/atk/gtk,gdk is generally thought of as a set. The versions should live in harmony, that is, glib2 with gtk2. You build it by compiling/installing in order: glib, atk, (Cairo and friends if using them), pango, gtk. Old glib1/gtk1 used stuff like "glib-config" in /usr/bin, and queried that to find version numbers, comparing what that script said against what it found in the installed headers. glib2 and friends use pkgconfig. Have a peek in /usr/lib/pkgconfig. You should see lots of *.pc files. Those files are in a special format that tell info about what's install on the system. Lots of things use pkgconfig, but lots doesn't. You can check a version, see cflags, and find other info by using the pkgconfig binary:
Code:
pkg-config glib-2.0 --modversion
2.8.6
pkg-config pango --modversion
1.10.4
pkg-config atk --modversion
1.10.3
pkg-config cairo --modversion
1.1.10
pkg-config libpixman --modversion
0.1.6
So, if you have glib1 likely you'll have glib-config in /usr/bin. Uninstalling glib1 would entail removing all its headers, its configure script "glib-config" (likely the part atk is finding left over from the old install), its *.a libraries in /usr/lib, and its documentation. I don't think it had a pkg-config script, but it's been awhile since I had glib1 on the system. Just look and see if there is one. I move the old shared libs down to /lib to indicated they are obsoleted off the system, but can still be used to run already-compiled binaries. If you think nothing is using them, move them to a trash area and use the system as usual. If after a month or so you didn't hear any "can't find shared object glib, gmodule, gobject, gthread" errors, then you can think of erasing them.
Since you're pulling glib1, you really should do atk, pango, cairo/libpixman/glintz/pango-cairo, and gtk/gdk at the same time, jump their versions up too. Most things build against glib2/gtk2 nowdays, with only a few things still wanting the first installment.
As in the first part of my reply, on a distro system the package manager should be taking care of this, but it can't hurt to know what's going on underneath the hood.
Also, you can trace thru ./configure scripts by looking at config.log after they've bombed. They have a record of what happened and what line number inside ./configure script it was at when it went wrong.
Last, usually glib, atk, gtk/gdk and friends sit in /usr/lib, which is always searched by the dynamic linker, so you should not have to touch neither /etc/ld.so.conf nor any LD_* variables. The only time you need those is if you are sticking .so libraries in a weird place and want your applications to be able to find them anyway, such as /usr/etc/bet/you/would/not/look/for/solibs/here.
Make sure to run ldconfig to rebuild the cache after installing/removing any shared libs. Libtool will usually do this for you, if you're using libtool. Notice also that glib != glibc.
Quote:
|
Package-managed systems such as SUSE, which are built with the intention that you only use their system (in this case, yast2) tend to behave really badly when you start ./configure && make && make install'ing packages - especially big important ones like glibc. The package management tool can't keep track of manually-installed packages and then everything just goes to heck.
|
I'll second that.
