Dear All, Walt Brainerd wrote on 2014-11-29: ----------------
> Yes, it appears that this is a little complicated. > I build static, but linking an application was missing a bunch of stuff. I don't have much direct or exhaustive experience here, and my gut agrees with Alan's advice that the more static stuff the better. We ship binary distributions of our QSAS application, which uses our own build of plplot (and only one driver, our original Qt widget driver, from which the modern plplot qt drivers were spawned). QSAS can't be 100% static because part of the architecture involves user-built and dynamically loaded plug-ins. So in practice we build essentially 100% shareable code and then bundle all the necessary dll's into a /lib folder. I've been meaning to test building a simple plplot application against those libs, but the small extra effort of forcing it to be built within a proper qt application has been enough to put it on the back burner. Our experience is that shipped Windows binaries tend to work pretty well across different versions of Windows platforms. We don't use CMake, but a simple bespoke build script under MSYS/Mingw (I've been meaning to try MSYS2). Bundling up QSAS for distribution means identifying all the library dependencies, and I've recently discovered "Dependency Walker" to provide a full view of the dll's needed. Most of these are system libraries that seem to be maintained and distributed with Windows despite the advancing operating systems. Then there are the qt libs, some other 3rd party ones, and a few from mingw (libstdc++, libgcc..., libwinpthread..., etc which are quickly identified in Dependency Walker's hierarchical view of the libs required at launch. I think it will also query individual dll's to locate their dependencies and also profile the run of an application to pick up, e.g., dynamic loading post-launch. Anyway, Windows seems to be remarkably robust to running binaries from other versions. This is in stark contrast to linux and macintosh, both of which are much fussier and temperamental. I am not a fan of Microsoft - far from it - but this aspect is fairly impressive. I suspect ( = I have no evidence or expertise ) that this works better if the binary is built on an old version of Windows and then shipped to newer ones than vice versa, as Windows tries hard to be backwardly compatible. No one could really expect them to be forward compatible. Finally, I have followed your discussion about font and map files. We "solve" this problem by putting them in the same directory as our main executable and have our batch startup script always run from within that directory. I think plplot will look in the current working directory to find them. I'll experiment with the PLPLOT_LIB approach, as it's a bit tidier. Best wishes Steve -------------------------------------------------------------------- Steven J Schwartz Phone: +44 (0)207 594 7660 Professor of Space Physics Fax: +44 (0)207 594 7772 Director, Imperial Space Lab www.imperial.ac.uk/spacelab The Blackett Laboratory Email: s.schwa...@imperial.ac.uk Imperial College London Office: Huxley 6M67A London SW7 2AZ, UK Web: www.sp.ph.ic.ac.uk/~sjs -------------------------------------------------------------------- ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
