Hi Phil: On 2014-08-30 00:17+0100 Phil Rosenberg wrote:
> Thanks Alan. I'll have a look at that over the weekend. But just so you know in both the static and dynamic build case the libraries are not linked into the plplot library. Yes, -DBUILD_SHARED_LIBS=ON or OFF (to use CMake terminology) either builds PLplot libraries as shared libraries and devices as independent shared DLL's or as static libraries (where the devices become part of the core library). But this CMake option says nothing at all about how external libraries are linked or whether the shared or static run time is used. > If I create a program and link in Plplot, then I must separately link all the libraries that Plplot uses. This is the case also for the examples. I can view the properties of each example project in visual studio and see the libraries that are linked in - which is Plplot and all the inherited dependencies. I'm not sure if this static behaviour is the same on linux - it's obviously much less common to link statically on that OS. There are three separate library linking issues. (1) linking PLplot libraries themselves (and only those libraries) as shared or static using BUILD_SHARED_LIBS to control that aspect; (2) linking external libraries (other than the run-time) as shared or static; and (3) using a shared or static run-time. On Linux and MinGW/MSYS/Wine I just take the default shared for (2) and (3) with no linking or run-time issues for both BUILD_SHARED_LIBS values. Of course, in the MinGW/MSYS/Wine case I have to be careful that the relevant external DLL's are on my PATH and similarly for the internal (PLplot) DLL's. Arjen's testing of Cygwin _and also_ MSVC with nmake has had similar success just using the default shared for (2) and (3). So I don't think you are going to run into trouble with MSVC and nmake by taking that same approach. If you look up the google terms <cmake force static> you will see that typically users get into a world of hurt by attempting static versions of (2) and (3). Static (2) is tricky because, for example, all external static libraries have to be mentioned in the right order. Years ago I tried that with PLplot (with one of our ancient build systems) and eventually got it to work, but it was painful so I have never tried static (2) again because it was so much trouble. I think static (3) is easier, but I have never tried it because I don't see the point unless (2) is static as well. All of this is, of course, a side issue to that one remaining .lib.lib linking issue, but I hope your full bug report will help me figure out that issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). 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 __________________________ ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
