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 > > -- > Покотиленко Костик <[EMAIL PROTECTED]>
> 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
