On Fri, Nov 19, 2010 at 10:51 AM, Donald Allen <donaldcal...@gmail.com> wrote:
> On Fri, Nov 19, 2010 at 10:22 AM, Derek Atkins <warl...@mit.edu> wrote:
>> Donald Allen <donaldcal...@gmail.com> writes:
>>
>>>>> Do `ldd /usr/local/lib/gnucash/libgncmod-app-utils.so` and make sure that
>>>>> libgnc-qof.so is in the list.
>>>>>
>>>>
>>>> d...@octavian:~$ ldd /usr/local/lib/gnucash/libgncmod-app-utils.so | fgrep
>>>> libgnc-qof
>>>> libgnc-qof.so.1 => /usr/lib64/libgnc-qof.so.1 (0x00007ffbc0dcd000)
>>>> d...@octavian:~$ find /usr/local -name libgnc-qof.so.1 -print
>>>> /usr/local/lib/libgnc-qof.so.1
>>>> d...@octavian:~$ nm /usr/local/lib/libgnc-qof.so.1 | fgrep
>>>> guid_g_hash_table_equal
>>>> 0000000000014510 T guid_g_hash_table_equal
>>>> d...@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:
d...@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
d...@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
d...@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
d...@octavian:/tmp$ ldd /usr/local/lib/gnucash/libgncmod-app-utils.so
[snip]
libgnc-qof.so.1 => /usr/lib64/libgnc-qof.so.1 (0x00007fa764559000)
[snip]
d...@octavian:/tmp$ echo $LD_LIBRARY_PATH
/usr/local/lib:/usr/local/lib/gnucash
d...@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]
d...@octavian:/tmp$ /usr/local/bin/gnucash
This is a development version. It may or may not work.
Report bugs and other problems to gnucash-de...@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
d...@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]
d...@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
>> warl...@mit.edu PGP key available
>>
>
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
