Hi Alan I think I have fixed it. In fact it turned out that test-drv-info was doing exactly what it should.
running ldd on the wxwidgets.so file revealed 3 dependencies that could not be found. The flavour of Linux I am building on is Arch, which maintains rolling upgrades of all packages rather than fixed update releases. Since the last wxWidgets release on Arch, the three dependencies had all upgraded with new ABIs. I built wxWidgets from source and now everything is working as it should. The lightbulb moment was realising that the function called in test-drv-info opens the requested library plus all its dependencies. On Tue, 11 Sep 2018 at 23:19, Alan W. Irwin <alan.w.irwin1...@gmail.com> wrote: > > On 2018-09-11 20:07+0100 Phil Rosenberg wrote: > > > Hi Alan > > I just wanted to let you know that your recent commit seems to have fixed > > all > > the strange output I was getting at the end of my cmake command. > > Hi Phil: > > I was very happy to receive that encouraging news concerning all the > build-system > improvements I have been doing. > > > > > I am still getting a build arror though > > Generating test_dyndrivers_dir/wxwidgets.driver_info > > Could not open driver module > > /home/users/prosenberg01/junest/src/plplot-plplot/build/drivers/wxwidgets > > libltdl error: file not found > > > > > > This comes down to the execution of an execuatable > > <build_dir>/drivers/test-drv-info. It is run as follows > > ./test-drv-info "" wxwidgets > > and it retuns an error, saying could not open driver module > > <build_dir>/drivers/wxwidgets > > > > I've found that test-drv-info is an executable built by plplot. It > > uses the function lt_dlopenext to open the drivers and then extract > > some symbols. From what I can tell from the source the lt_dlopenext > > function returns null indicating the file did not exist or could not > > be opened. The relevant file (wxwidgets.so) is definitely there, so I > > guess there must be some reason why it cannot be opened. > > > > I'm at a complete loss now as this is beyond my linux knowledge - any > > suggestions? > > The test-drv-info application was implemented long ago to test at > build time whether our dynamic devices would load properly. But > sometimes on Windows (but never on Linux) test-drv-info would say the > device could not be loaded properly, but the equivalent code to > dynamically load a device in the PLplot core library would work fine! > But our Windows developers could never figure out that discrepancy > between the two results. > > Anyhow, you *might* have run into this case yet again. So to check > that specify -DTEST_DYNDRIVERS=OFF (which will drop the build-time > test). That should let you build everything without problems, but, of > course, you should test that result at run-time to make sure the > equivalent code in the core library works, i.e., by specifying -dev > wxwidgets for some run-time test. > > If that turns out to be the case, (i.e.,test-drv-info application does > not work while equivalent core code does work), that is a useful > workaround for you, but it would also be great in this case if you > could figure out the fix required to make sure test-drv-info works > *exactly* like the core code on your Windows platform so you don't > have to use the workaround. > > Alan > __________________________ > Alan W. Irwin > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
