Re: [Evolution-hackers] GIT master failing evolution-data-server build...

[Paul Smith <paul mad-scientist net>]

On Mon, 2010-04-26 at 14:48 +0200, Milan Crha wrote:
> I do not see these myself, but from other experience I believe it's
> linking to wrong GLib, to the older one, than it is compiled with, or
> some other module it is linking to itself is using a newer GLib.

I've discovered you're correct.

We have a very unfortunate situation now.  There is a requirement I saw
on the lists (can't find it now though... I'll keep looking) that if we
are using Evo from an alternate installation we have to add that path
into ld.so.conf (or, as my makefile does it, a new file in ld.so.conf.d)
so that the libraries can be located.

In the past all that's been necessary is to set LD_LIBRARY_PATH before
invoking Evo.  But now apparently some applications are being invoked as
shared libraries by some infrastructure components (dbus?  Not sure...
Matthew probably knows more) which are always running, and hence do not
have the right LD_LIBRARY_PATH setting, hence the need to change
ld.so.conf.

The problem with this is for building the master Evo git I apparently
need a new glib.  For building Evo 2.30, I do not need a new glib.  But,
because the Evo master git install directory is added to ld.so.conf, all
my applications are now finding and using that version of glib (etc.!)
rather than the on-host ones, at runtime, even though at link time I
appear to be linking against the non-master, system versions.


I wonder if there isn't some other way to use whatever infrastructure
component we need now, that causes the ld.so.conf issue, in such a way
as to avoid this problem.  For example maybe we could provide some kind
of fully-qualified path rather than just an so name?

Anyway for now I've abandoned building installing both 2.30 and git
master on the same system; this seems like it cannot work, unless I'm
willing to switch the ld.so.conf.d files back and forth by hand.