Re: gtk install problems



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 cvine freeserve co uk> 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






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]