Building gnucash on Ubuntu 12.04 Alpha
jralls at ceridwen.us
Fri Jan 27 01:07:09 EST 2012
On Jan 26, 2012, at 2:04 PM, Colin Law wrote:
> On 26 January 2012 17:11, Colin Law <clanlaw at googlemail.com> wrote:
>> On 26 January 2012 16:58, Geert Janssens <janssens-geert at telenet.be> wrote:
>>> Op donderdag 26 januari 2012 15:34:32 schreef Colin Law:
>>>> On 25 January 2012 16:54, Colin Law <clanlaw at googlemail.com> wrote:
>>>>> It seems I have been barking up the wrong tree here. I have built the
>>>>> trunk from git and it runs fine, without setting LD_LIBRARY_PATH.
>>>>> Moreover if I remove libgnome.so it still runs fine. I have checked
>>>>> that the only instance of libgnome.so on the system is the one in
>>>>> /usr/lib/libglade/2.0. So the question appears to be not why can the
>>>>> 2.4 build not find the library at run time, but why is it looking for
>>>> Not knowing where to go from here I tried the base of the 2.4 branch
>>>> and was surprised to find that it also fails. As I said above the tip
>>>> of trunk is ok. Now starting a bisect on the trunk to see where the
>>>> problem went away on the trunk. Obviously it is going to take a
>>>> little time as I am doing a clean build at each one.
>>>> If anyone had a brainwave it would be helpful. To summarize the problem.
>>>> Building the 2.4 branch on Ubuntu 12.04 I find that when gnucash is
>>>> run it cannot find libnome.so unless I set LD_LIBRARY_PATH
>>>> Building the tip of trunk does not have this problem.
>>>> Building the base of 2.4 branch *does* have the problem so something
>>>> has changed on the trunk since then to fix it.
>>>> The problem is not seen on Ubuntu 11.10
>>> Additionally you could also check what the result is of
>>> ldd /usr/lib/libglade/2.0/libgnome.so
>>> and if this reports some missing libraries. From how everything is installed,
>>> it looks like libglade is dlopening the libraries in /usr/lib/libglade/2.0/
>>> manually on demand, which might fail if libgnome.so is missing some
>>> dependencies. I don't know for sure, just thinking out loud.
>>> By the way, on Fedora 16, libgnome.so is installed via libgnomeui.
>> libgnome.so is installed via libgnomeui-0
>> ldd shows a big list of dependencies but is not showing anything
>> obviously wrong. Would it be obvious if something were missing?
> When I run
> /lib/ld-linux.so.2 --list /usr/bin/gnucash2.4/bin/gnucash
> it shows no errors, and in particular
> /lib/ld-linux.so.2 --list /usr/bin/gnucash2.4/bin/gnucash | grep libgnome
> libgnome-2.so.0 => /usr/lib/libgnome-2.so.0 (0x00117000)
> libgnomeui-2.so.0 => /usr/lib/libgnomeui-2.so.0 (0x00588000)
> libgnome-keyring.so.0 => /usr/lib/libgnome-keyring.so.0 (0x00a77000)
> libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0x00dd8000)
> libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0 (0x133eb000)
> which suggests to me (with my very limited knowledge of how this all
> works) that gnucash should not be looking for libgnome.so in the first
> The error in gnucash.trace is
> WARN <libglade> Could not load support for `gnome': libgnome.so:
> cannot open shared object file: No such file or directory
> I am wondering whether there is a bug in libglade (or something else)
> that is causing it to look for the wrong file at run time and it is
> nothing to do with gnucash at all.
> Unless anyone has any good ideas I am going to leave it at that for
> the moment, I will add the notes for building on 12.04 to
> http://wiki.gnucash.org/wiki/Building including the requirement to
> setup LD_LIBRARY_PATH for the 2.4 branch. Then I will keep an eye on
> the situation and see if the issues disappears with an upgrade to
> something else.
There are two libgnome.so in play here. It's a bit clearer in OSX, where loadable modules are called foo.so and shared libraries are called foo.dylib. It turns out that there's lib/libgnome.dylib and lib/libglade/2.0/libgnome.so. *The latter depends on the former.*
It's likely that it's lib/libgnome.so (which would be libgnome.dylib in OSX) which is installed by libgnomeui. lib/libglade/2.0/libgnome.so is obviously installed by libglade, but the libglade package maintainer might have messed up the second-order dependencies for *that* libgnome.so. It's his job to make it work, so you should be talking to him about the problem. He's certain to know more about the subtleties of it than is anyone here.
More information about the gnucash-devel