What does ABI mean? What I would love is for someone to explain to me in the most technical way possible why this is occurring. Not different versions of libraries, obviously I have different versions of libraries installed. And not some pkg-config thing because then the other libraries shouldn't have compiled in the first place, that's what pkg-config is for. Even if pkg-config had the wrong path, if the libraries were the wrong version the configure script should have choked. What's this thing with g_prgname? Why would such a variable not hold the same string across two accesses? Is that because there's two different interfaces to g_prgname and in my case those two different interfaces are on libraries with incompatible versions? What's confusing to me is that the configure scripts in gtk and glib find the right libraries, they compile with those libraries, but then programs that use gtk and glib don't run with strange errors. Whether or not I have two sets of libraries installed for the same software seems irrelevant. I initially recompiled X because something needed the X headers and the header packages from Xorg didn't match my libraries and at this point dselect (debian package manager) wanted to replace my kernel because it wasn't what was expected. I've compiled X before and it wasn't and shouldn't be that much of a problem. But please tell me something interesting. Like that g_prgname thing, how does that happen? On 5/12/07, Chris Vine <chris@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2007-05-11 at 01:58 -0400, Peter wrote: > > Paul, > > All the installs were the defaults for the installs. I didn't do > > anything strange. > > > > I do not know what ABI stands for but I would like to know. > > Application... bridging interface? That seems redundant. > > > > As I said, I do think I have conflicting versions of libraries > > somewhere although I have tried to go through and ensure only one of > > each. > > > But I think the real hint here is that its only certain applications > > that fail and generally with the same issues. For instance, right now > > I'm running firefox as it was installed from a package in the > > enlightenment window manager as I compiled and installed after these > > issues occurred. > > If you have re-compiled X and compiled gtk+ and its dependencies in the > default prefix, that would have put them in the /usr/local prefix. At > the same time you will have X from your distribution (any any other > system software you tried to recompile) installed in either /usr > or /usr/X11R6. When you try to launch a program it will be picking up > the wrong libraries. > > There is no reason why you should have needed to recompile X. You could > try deleting everything under /usr/local and get the pre-installed > libraries from your distribution working again, if need be by > reinstalling your distribution from CDROM/DVD. > > You then need to find out what dependencies for gtk+ your distribution > does not have precompiled, and just install those from source. > > Note that if you install from source in /usr/local, you will have to > make sure that /usr/local/lib is specified in /etc/ld.so.conf (and run > ldconfig whenever you change /etc/ld.so.conf), and that PKG_CONFIG_PATH > contains a reference to /usr/local/lib/pkgconfig. If it doesn't, you > can deal with it by doing: > > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig > > before running ./configure on that shell. > > It is quite unusual for a distribution not to come with gtk+ > precompiled. Most do, even if they do not come with GNOME. > > Chris > > > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
