guid_g_hash_table_equal

Donald Allen donaldcallen at gmail.com
Sun Nov 21 07:56:48 EST 2010


On Sun, Nov 21, 2010 at 5:24 AM, Geert Janssens
<janssens-geert at telenet.be> wrote:
> On Friday 19 November 2010, Donald Allen wrote:
>> 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
>>
> Donald,
>
> Thinking more about this, you may have hit a subtle bug that only pops up on
> 64-bit architectures.
>
> You should know that other than your LD_LIBRARY_PATH manipulation, GnuCash
> also manipulates that path during startup. So it changes LD_LIBRARY_PATH after
> you have done so.
>
> From reading the code, this could pose problems if you have disabled bin-reloc
> and not specifying a prefix at configure time. Perhaps there are even other
> scenarios that could lead to the same problem, but I can't test that myself as
> I don't have a 64-bit system here.
>
> Did you disable binreloc ?

No.

>
> In any case I see two potential workarounds:
> * During build, run configure with the --prefix option explicitely set to
> something other than /usr/local, for example set it to
> /home/myuser/gnucashroot or something like that.

Ok. Derek also recommended this and I didn't understand why this makes
a difference then and don't now, but I don't have to, if it works :-)
>
> or maybe this also works:
>
> * After you have installed gnucash in /usr/local, edit
> /usr/local/etc/gnucash/environment. In that file you will find a line that
> alters LD_LIBRARY_PATH. You may try to add your changes in that line. Make
> sure you add your modfication BEFORE the {SYSLIB} parameter. Additionally, you
> may still have to set your LD_LIBRARY_PATH on the command line as well before
> calling gnucash. The current startup code has some weird wrinkles I'm afraid.
>
> Can you let us know if either (or both) of these work(s) ?

Sure. I'll get back to you when I've tested them.

Re your comment above that the startup code has "weird wrinkles", once
we sort this out and figure out what works in installing a test
version side-by-side with a packaged released version, we should add a
short paragraph somewhere that documents what we've learned (to the
extent that we learn anything new that isn't already documented), so
others don't trip over this.

/Don

>
> Geert
>
>


More information about the gnucash-devel mailing list