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. _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers