guid_g_hash_table_equal

Donald Allen donaldcallen at gmail.com
Fri Nov 19 12:38:43 EST 2010 

On Fri, Nov 19, 2010 at 10:51 AM, Donald Allen <donaldcallen at gmail.com> wrote:
> On Fri, Nov 19, 2010 at 10:22 AM, Derek Atkins <warlord at mit.edu> wrote:
>> Donald Allen <donaldcallen at gmail.com> writes:
>>
>>>>> Do `ldd /usr/local/lib/gnucash/libgncmod-app-utils.so` and make sure that
>>>>> libgnc-qof.so is in the list.
>>>>>
>>>>
>>>> dca at octavian:~$ ldd /usr/local/lib/gnucash/libgncmod-app-utils.so | fgrep
>>>> libgnc-qof
>>>>         libgnc-qof.so.1 => /usr/lib64/libgnc-qof.so.1 (0x00007ffbc0dcd000)
>>>> dca at octavian:~$ find /usr/local -name libgnc-qof.so.1 -print
>>>> /usr/local/lib/libgnc-qof.so.1
>>>> dca at octavian:~$ nm /usr/local/lib/libgnc-qof.so.1 | fgrep
>>>> guid_g_hash_table_equal
>>>> 0000000000014510 T guid_g_hash_table_equal
>>>> dca at octavian:~$
>>>>
>>>
>>> I have a guess about what's going on here. I'm not sure what the output of
>>> ldd is saying (the ld man page is amazingly unhelpful, a reminder of the bad
>>
>> ldd is saying that /usr/local/lib/gnucash/libgncmod-app-utils would be
>> loading libgnc-qof.so.1 from /usr/lib64/libgnc-qof.so.1.  I.e., Your
>> build is improperly interacting with a packaged version.
>
> Yep, already figured that out. And would have saved myself some time
> if I'd read the release notes carefully, which predict bad things if
> you do what I did (as I mentioned in an email yesterday).
>
>>
>> This is one of many reasons I always recommend that people doing
>> development use a "prefix build":
>>
>>  ./configure --prefix=/opt/gnucash
>
> I guess I don't understand why this makes a difference. Without
> --prefix, my understanding is that the default prefix is /usr/local,
> yes? If I'm right, then there's no physical interference with
> Slackware packages, which are installed in /usr, like every other
> Linux distribution that I am aware of (and unlike things like OpenBSD,
> which puts user-installled packages in /usr/local). I *think* the
> problem here was the presence of /usr/lib64/libgnc-qof.so.1 on my
> system, which was there courtesy the install of the 2.2.9 Slackware
> package. 2.3.16 was behaving as if it was linking with that file,
> rather than the correct one in /usr/local/lib.
>
>>
>> This will cause the build system to use library load-path encodings in
>> the shared objects so that it will find your built libs first.
>>
>>> old 4.1BSD days on overloaded Vax 780s, where we joked "it was hard to
>>> build, it ought to be hard to use"), but I'm guessing that it's saying that
>>> the dynamic loading of libgnc-qof.so.1 is going to come from
>>> /usr/lib64/libgnc-qof.so.1, which is there courtesy the Slackware 2.2.9
>>> package that is installed. If I'm right, that's the wrong version of that
>>> library. I suspect that having 2.2.9 installed has confused things. Does
>>> this sound plausible or am I tilting at windmills? If I'm right, then I
>>> should remove the 2.2.9 package and re-link?
>>
>> You're right in your analysis, but somewhat incorrect in your
>> conclusions.  You do have two options:  Remove 2.2.9, or rebuild into a
>> prefix build.  There was no reason that you needed to rebuild/relink
>> into /usr/local.
>>
>> Actually, there's also a third option, set LD_LIBRARY_PATH when you run
>> gnucash so that it looks into /usr/local/lib first.
>
> Well, I have evidence to the contrary. I *did* set LD_LIBRARY_PATH to
> /usr/local/lib:/usr/local/lib/gnucash prior to running the first build
> I did and still got the undefined reference error on startup (this is
> shown clearly in my original post that started this thread). According
> to the ld man page, LD_LIBRARY_PATH is searched before the "default"
> locations (/lib, /usr/lib, and, I would imagine, /usr/lib64, though it
> doesn't say that explicitly). If this is correct and the searching was
> happening at runtime (I say this because LD_LIBRARY_PATH was NOT set
> at link time), what you say and what I did should have worked. But it
> didn't. I don't pretend to know what's going on here, but it was
> behaving as if either some things got resolved at link time, or the
> search path, including LD_LIBRARY_PATH, isn't in the order that the
> man page seems to suggest and that we both seem to think it is.  What
> I didn't think to do, and should have, was to try running the first
> build after removing the 2.2.9 package, but with LD_LIBRARY_PATH set
> as above. If *that* had worked, it would tell us that the library
> search path isn't in the order we think it is. I'll  try reinstalling
> the 2.2.9 package to correct that oversight, and see if that breaks
> 2.3.16 in the same way I saw yesterday. I'll let you know what
> happens.
>
> /Confused

After re-installing the 2.2.9 package:

dca at octavian:/tmp$ /usr/local/bin/gnucash
/usr/local/bin/gnucash: symbol lookup error:
/usr/local/lib/gnucash/libgncmod-app-utils.so: undefined symbol:
guid_g_hash_table_equal
dca at octavian:/tmp$ find /usr -name gnucash -print
/usr/local/etc/gnucash
/usr/local/etc/gconf/gconf.xml.defaults/schemas/apps/gnucash
/usr/local/etc/gconf/gconf.xml.defaults/apps/gnucash
/usr/local/include/gnucash
/usr/local/bin/gnucash
/usr/local/lib/gnucash
/usr/local/share/gnucash
/usr/local/share/gnucash/guile-modules/gnucash
/usr/local/libexec/gnucash
/usr/share/xml/gnucash
/usr/share/gnucash
/usr/share/gnucash/guile-modules/gnucash
/usr/include/gnucash
/usr/lib64/gnucash
/usr/bin/gnucash
/usr/libexec/gnucash
dca at octavian:/tmp$ find /usr -name 'libgnc-qof*' -print
/usr/local/lib/libgnc-qof.so.1.0.4
/usr/local/lib/libgnc-qof.so.1
/usr/local/lib/libgnc-qof.so
/usr/local/lib/libgnc-qof.la
/usr/lib64/libgnc-qof.so.1.0.4
/usr/lib64/libgnc-qof.la
/usr/lib64/libgnc-qof.so.1
/usr/lib64/libgnc-qof.so
dca at octavian:/tmp$ ldd /usr/local/lib/gnucash/libgncmod-app-utils.so
        [snip]
	libgnc-qof.so.1 => /usr/lib64/libgnc-qof.so.1 (0x00007fa764559000)
	[snip]
dca at octavian:/tmp$ echo $LD_LIBRARY_PATH
/usr/local/lib:/usr/local/lib/gnucash
dca at octavian:/tmp$ sudo removepkg /var/log/packages/gnucash*

Removing package /var/log/packages/gnucash-2.2.9-x86_64-2_SBo...
Removing files:
  --> Deleting symlink /usr/lib64/gnucash/libgncmod-qif.so
  --> Deleting symlink /usr/lib64/gnucash/libgncmod-qif.so.0
  --> Deleting symlink /usr/lib64/libgnc-backend-file-utils.so
  --> Deleting symlink /usr/lib64/libgnc-backend-file-utils.so.0
  --> Deleting symlink /usr/lib64/libgnc-business-ledger.so
  --> Deleting symlink /usr/lib64/libgnc-business-ledger.so.0
  --> Deleting symlink /usr/lib64/libgnc-core-utils.so
  --> Deleting symlink /usr/lib64/libgnc-core-utils.so.0
  --> Deleting symlink /usr/lib64/libgnc-gnome.so
  --> Deleting symlink /usr/lib64/libgnc-gnome.so.0
  --> Deleting symlink /usr/lib64/libgnc-module.so
  --> Deleting symlink /usr/lib64/libgnc-module.so.0
  --> Deleting symlink /usr/lib64/libgnc-qof.so
  --> Deleting symlink /usr/lib64/libgnc-qof.so.1
  [snip]
dca at octavian:/tmp$ /usr/local/bin/gnucash


This is a development version. It may or may not work.
Report bugs and other problems to gnucash-devel at gnucash.org.
You can also lookup and file bug reports at http://bugzilla.gnome.org
The last stable version was GnuCash 2.2.9
The next stable version will be GnuCash 2.4

libmysqlclient.so.15: cannot open shared object file: No such file or directory
libdbi: Failed to load driver: /usr/lib64/dbd/libdbdmysql.so
  C-c C-c
dca at octavian:/tmp$ ldd /usr/local/lib/gnucash/libgncmod-app-utils.so
	[snip]
	libgnc-qof.so.1 => /usr/local/lib/libgnc-qof.so.1 (0x00007f657ff14000)
	[snip]
dca at octavian:/tmp$

This behavior is consistent with searching /usr/lib64 and *then* what
is specified by LD_LIBRARY_FLAGS.

I don't pretend to understand the makefiles, but there's a lot of this
kind of thing:

GUILE_LIBS =  -pthread -L/usr/lib64 -lguile -lltdl -lgmp -lcrypt -lm -lltdl
./libqof/qof/Makefile

so I wonder if the makefiles are getting /usr/lib64 into the search
path before what's in LD_LIBRARY_FLAGS.

/Still confused



>
>>
>> But I still maintain that prefix build is the best route.
>>
>>> /Don
>>
>> -derek
>>
>> --
>>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>>       Member, MIT Student Information Processing Board  (SIPB)
>>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>>       warlord at MIT.EDU                        PGP key available
>>
>

More information about the gnucash-devel mailing list