On donderdag 1 december 2011, John Ralls wrote: > On Dec 1, 2011, at 1:56 PM, Geert Janssens wrote: > > On donderdag 1 december 2011, John Ralls wrote: > >> On Nov 30, 2011, at 5:05 PM, John Ralls wrote: > >>> On Nov 30, 2011, at 8:44 AM, Derek Atkins wrote: > >>>> John Ralls <[email protected]> writes: > >>>>> I've just committed the requisite fixes, and distcheck now works on > >>>>> my Mac. But there's an older problem that causes make check to fail > >>>>> on Debian Squeeze and Fedora 12 if Gnucash hasn't been installed. > >>>>> Since distcheck does exactly that, it fails too. I'm bisecting to > >>>>> try and figure out what is the quick fix (after banging on it for > >>>>> three days *didn't* solve the problem). > >>>>> > >>>>> The actual problem is the way we retrieve some modules, using > >>>>> gnc_path_get_stdreportdir() (for standard reports) and > >>>>> gnc_path_get_pkglibdir() (for the engine backends). Neither of those > >>>>> as written will work with uninstalled libraries, so the tests > >>>>> fail. But that change went in early last year, and the tests didn't > >>>>> start failing until a changeset from some time this spring. > >>>> > >>>> Perhaps the TEST_ENVIRONMENT is not set correctly to point to the > >>>> correct build directories? > >>> > >>> No, the path utilities don't pay any attention to the environment. I'm > >>> working on changing that. > >> > >> In fact, it looks like the report tests broke when Geert *fixed* the > >> test environments, because it wasn't actually trying to run the tests, > >> just giving up and passing because it couldn't find the modules. Geert > >> didn't see the error, of course, because he had run "make install" at > >> some point, so the test was able to find the reports and the backends. > > > > Interesting, so my fixes actually revealed a bug in the module testing > > code. > > > > If I find some time, I will run this experiment on Fedora 15 as well and > > see what happens. > > > > There was a part in the test Makefiles I wasn't sure about that may be > > related: the GNC_TEST_DEPS contains a number --library-dir lines. Should > > these point to all build directories with required modules ? I thought > > this was superfluous because the module loading code adds all > > gnc-module-dir paths to LD_LIBRARY_PATH already. But I haven't looked > > into this in much detail. > > That might be an OSX adaptation, where LD_LIBRARY_PATH is for finding > loadable modules (i.e., dlopen()) and DYLD_LIBRARY_PATH is for finding > shared libraries. Without the --library-dir lines, OSX can't find the > shared libraries needed by the modules, so they don't load. > > Having written the fix for loading the backends, I'm working through the > tests getting everything that was barfing for being unable to load modules > and passing anyway to pass correctly. After I've got everything working > for the engine problem, I'll get the standard-report problem, and then go > look for other things that have the problem. One issue is that failing to > load a module at most prints an error message but still allows the test to > pass. We need exceptions... :-( > > On that vein, I'd really like to get to the bottom of the duplicate symbols > in sw_engine and gnucash engine spew, but what sw_engine is and where it > comes from eludes me. > Yes, I hit that one too and intially removed the duplicate symbols in the engine.i file. With that change the tests work fine, but reports crash. So I reverted that part of the patch in r21589 and Mike Evans reverted the equivalent change for sw_app_utils in r21625. I haven't had time since to look into this again.
I did more or less figure out at that time what sw_engine is. The way I understand it currently is that sw_engine is the guile interface to the swig generated engine wrapper. It is a (quile) module that gets created by swig based on the engine.i file. Everything you define in engine.i will end up being exported via module sw_engine (I guess). The warnings all deal with symbols that are wrapped in engine.i (they come from gnc-engine.h which is %included in engine.i) and are also exported in engine.scm. For some reason the tests consider this a duplicate symbol definition, but the reports require the export statements or will fail to work. That's as far as I got. I don't know why this is though, because at first sight, the sw_engine module is loaded by default when gncmod_engine is loaded (see gncmod- engine.c). And yet the tests complain about duplicate symbols, while the main program doesn't. Geert _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
