Can't save in r12331

[Chris Shoemaker]

On Fri, Jan 13, 2006 at 08:20:56PM +0200, Покотиленко Костик wrote:
> > If not, do you see errors in /tmp/gnucash.trace?
> 
> It's saying something nasty, attached
> 
> -- 
> Покотиленко Костик <casper at meteor.dp.ua>

> gnucash: failed to open libtool archive "NONE/lib/libqof-backend-qsf.la"
> 
> gnc_engine_init: assertion `(qof_load_backend_library (QOF_LIB_DIR, "libqof-backend-qsf.la", "qsf_provider_init"))' failed

Aacck!  Why are we hard-coding a ".la" module suffix?  Do we not trust
GModule to find the right library?  But, that's probably not the
_real_ problem...

> Initialization failed for module gnucash/business-core-file
> 
> Unable to read file /home/casper/.gnucash/expressions-2.0: File is empty
> 
> gnucash: NONE/lib/libqof-backend-qsf.so: cannot open shared object file: No such file or directory
> 

I have a pretty good idea what's happening here.  I hadn't taken a
look at QOF's module loading mechanism before today, but that is
basically the problem.

This is very closely related to what is also causing test-customer to
fail with basically the same message in
src/business/business-core/test/.  QOF uses a compile-time path
(QOF_LIB_DIR) to find libraries.  Yours wasn't set.  It's a bug in our
configure.in.  We need to set QOF_LIB_DIR even if we're using QOF
internally.  A very short-term is to revert to r12330 and make sure to
use --without-qof if there's a chance you have an external QOF
installed.

One thing that bugs me is that the failing to locate QOF modules
doesn't fail more obviously and loudly.  We should basically exit(1)
on failing to load the backend.

-chris