guid_g_hash_table_equal

[Donald Allen]

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

>
> 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
>