Hi Alan Re docbook, I basically ran into a dead end. I couldn't get the correct fonts install. I didn't think changing the fonts was really a sustainable option unless you are interested in changing them permanently?
Re the dll issue, I'm not sure that was me as I never use DLLs, but maybe it was and I lost track of a thread. If it was then sorry for leaving it hanging. So if it is just a case of setting the path then that is both easy and a bit frustrating. I have a usr/local/bin directory in which I store compiled binaries and this is where the plplot DLLs end up. This folder is in my path all the time and it is where the examples obviously find the DLLs. Changing this path to run the examples is a bit of a pain, but now I know this is the situation I will simply make sure I run the INSTALL project before I try to debug the examples to make sure I have up to date DLLs. Phil -----Original Message----- From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> Sent: 27/10/2014 17:47 To: "phil rosenberg" <philip_rosenb...@yahoo.com> Cc: "PLplot development list" <Plplot-devel@lists.sourceforge.net> Subject: Re: [Plplot-devel] Why is the set_stream() call commentedoutforplstream::fill, etc. On 2014-10-27 11:30-0000 phil rosenberg wrote: > Hi Andrew and AlanSo I believe I have fixed this issue now. I have put the callback functions in a plcallback namespace, which I felt was the best way to identify them for use as callback functions. Thanks! > I will update the docs and commit the changes - although it would be good if one of you could check that the docbook still builds fine as I don't have an easy way to check that on my Windows PC (I will, when I get time make sure I have the requirements for docbook builds on my Linux PC so I can test these in the future, albeit with a bit of messing around copying stuff backwards and forwards). We previously covered the topic of building the docs on Cygwin, but that was left hanging (possibly because of your subscription problems?). You were having trouble with fonts, and I gave you some advice about installing those and/or shifting to other fonts. Did you receive that e-mail? But even if you don't want to pursue the Cygwin doc build option further, I suggest you install at least onsgmls on Cygwin so your DocBook changes can be validated at least. (Which is advice I also gave you in previous e-mail.) Of course, regardless of how far you want to go on Cygwin to either generate your new documentation or at least validate it (or switch to Linux to do the same thing) I will be taking a look at your changed results as well. > However I had an odd obstacle when testing the fix. Initially I was getting runtime issues with not finding the functions in the dll. Eventually with the help of Dependency Walker I found that when running the examples from the build tree, the dlls were being loaded from the install directory, so it was loading an out of date library. If I removed the dll from the build directory then the dll was not found at all. I'm not entirely sure how the libraries are loaded, but I just wanted to check that this is the expected behaviour or whether the libraries should be loaded from the build tree when run from the build tree? You have brought up this issue before which was also left hanging. I responded at the time, but never got a further reply from you (possibly because of your subscription problems). So let's go through this again. On Windows platforms that use the command line (MinGW, Cygwin, and nmake builds on bare Windows) and for shared libraries builds, the user should set the PATH appropriately to find the right set of dll's. For the build tree, the dll's for both libraries and device drivers are located in the dll subdirectory of the build tree. For the install tree, the dll location is $INSTALL_PREFIX/bin. For your MSVC case, where are the dll's located in the build tree and install tree? (This is an important question I have asked you before.) If it is the same as above, then all you have to do is set your PATH appropriately (as in all other Windows platforms). But since that is a trivial fix, and you are having trouble with this, I suspect the dll's in the build tree are not collected in the correct location for your MSVC case. If this proves to be the case, then we will likely need to give up our use of an ancient legacy CMake variable to control build-tree location of the dll's, and use modern CMake methods instead to do that. But before figuring out the fix, I need you to answer that key dll location question. 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 __________________________
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
