Re: [Plplot-general] Plplot on Mingw

[Walt B. <wal...@gm...>]

Thanks again, Alan, Arjen, Steven for taking the time to
provide so much information.

I think I will put what I have in the next version of the Fortran
Tools, since it *does work* and then definitely have a look
at MinGW/MSYS and the Dependency walker.

The other new thing I will include is Glade. It is a nice GUI
for building GUIs, but, unfortunately, has no reference manual,
just a couple of tutorials. The Plplot manual is so nice, by
comparison.

On Sat, Nov 29, 2014 at 5:23 AM, Schwartz, Steven J <
s.s...@im...> wrote:

> 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.s...@im...
> Imperial College London            Office: Huxley 6M67A
> London SW7 2AZ, UK                 Web:    www.sp.ph.ic.ac.uk/~sjs
> --------------------------------------------------------------------
>
>
>


-- 
Walt Brainerd