Re: [Plplot-devel] [Plplot-general] MinGW Make Trouble
David Mertens wrote: On Sat, Feb 6, 2010 at 10:15 AM, Hazen Babcock hbabc...@mac.com mailto:hbabc...@mac.com wrote: The problem is that the dll's that it made are not in your PATH. If you look in your build directory there should be a folder called dll. Once you add that to PATH you should be able to build ok. Hazen, that worked! Thanks! Upon closer inspection of the wiki, I see that it mentions setting up the path, but I didn't realize how critical that would be. I will continue to mess around with this and get back to y'all with questions as they arise. Any thoughts on configuring the build to automatically change PATH on windows to include the dll directory? Is this only a issue with mingw? -Hazen -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] MinGW Make Trouble
Hi Hazen:
My response below is mostly directed to you, but Werner should note there is
a question for him at the end.
On 2010-02-10 11:27-0500 Hazen Babcock wrote:
David Mertens wrote:
On Sat, Feb 6, 2010 at 10:15 AM, Hazen Babcock hbabc...@mac.com
mailto:hbabc...@mac.com wrote:
The problem is that the dll's that it made are not in your PATH. If
you look in your build directory there should be a folder called
dll. Once you add that to PATH you should be able to build ok.
Hazen, that worked! Thanks! Upon closer inspection of the wiki, I see
that it mentions setting up the path, but I didn't realize how critical
that would be. I will continue to mess around with this and get back to
y'all with questions as they arise.
Any thoughts on configuring the build to automatically change PATH on
windows to include the dll directory?
I think that is an excellent goal, but I am not sure how you could implement
it. The problem is that it's usual for changes in environment variables to
affect the current environment and for programmes called from the current
environment, but nothing else.
For example, the CMake documentation says you can, e.g.,
set( ENV{PATH} /home/martink )
but I think that would only work during the time when the cmake command was
being run but would not affect the subsequent build. Of course, I could
be wrong so you might want to try some experiments to see what is possible.
Werner, your combined knowledge of windows and CMake makes you the obvious
candidate to ask Windows-related questions in an informed way on the CMake
list. Therefore, would you please ask on that list whether there is a way
for cmake to set up Windows builds to allow dll's to be found or is it a
necessity to externally set the PATH?
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); PLplot scientific plotting software
package (plplot.org); 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
__
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] MinGW Make Trouble
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Werner, your combined knowledge of windows and CMake makes you the obvious candidate to ask Windows-related questions in an informed way on the CMake list. Therefore, would you please ask on that list whether there is a way for cmake to set up Windows builds to allow dll's to be found or is it a necessity to externally set the PATH? If a executable is run and a dll is needed, Windows looks first in the current directory for the dll. Then in the PATH. Then in c:\windows\system32 (and in some other system directories. Maybe PATH comes later, but this doesn't matter). Since we don't want to copy the dlls multiple times, our only chance is to change the PATH environment variable. I just read the cmake documentation about setting environment variables (http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set) and it should be possible to change the PATH variable that way. Presumably only as long as the Terminal window is open (so at least for the cmake configure stage). If you close the terminal, start it again this change is surely gone and I assume, if you then compile plplot (which is already configured) PATH won't be changed again, so you run into problems again. So this is no solution. Actually there are two problems. 1) plplot build is not finished, since testing the rc files fails, due to the missing dlls. I would suggest that for windows we force that the test-drv-info executable will be built into the dll folder (where for windows all dlls are gathered). Therefore the build gets through (since the dlls are in the same folder than test-drv-info). 2) The examples don't run, since the dlls are not found. Now you need to either set the PATH variable or copy the dlls. User interaction is needed, the dlls are in the dll directory and the examples are in the examples directory, and this shouldn't be changed. So IMO the best we can do is, that in summary.cmake we add at the end a message (with many !) if it's a shared build on Windows and examples are built as well, the user is asked to add the dll directory to the PATH variable. I believe the most Windows developers know about what to do, if they run a program and a message box pops up telling him that the dll is missing. Still not perfect, but on the other hand it's not possible to cover everything. If the user wants to compile his own executables, he *must* take care of the dlls anyway. So if he doesn't RTFM it's best he gets into trouble trying to run the examples already. It would be more confusing if the examples run and his own programs not. Regards, Werner 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); PLplot scientific plotting software package (plplot.org); 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 __ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sme...@iap.tuwien.ac.at (GPG: EDCAF4A79) web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLcwt0AAoJEG1QQcXtyvSnysAH/2er6WreXtol6WecBiPdMWMa U0v1E2C3iDtHyP00XOwvLFPepAF3fyqRdEkobaK3Wh1JcGllWvSRrrfkL3uEByIg 08Cx+bEhiMk8CF35W59bp7QbyLrEKT1XAMGLbAy53OUBYNW5usxcFB6DGJzq63B8 chkl6xNAAgOA0rBvUuNhdBeo38Bin1Ai5npJkJ1Sz4SCL1S6aXyi5SjThaZMiNyk 0B/bgxIhT7OI4hLUf4+Ug22GptnmdxGBWFVpRJE68aupe7a5knspRWDTAXirDTdf E6td7yJhoiA/y7DWe1PrCphYLTkXKCGBvCvWGZLGggxC2eri8wBS3wJl8YtBtkY= =ecTY -END PGP SIGNATURE- -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] MinGW Make Trouble
On 2010-02-10 20:39+0100 Werner Smekal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Werner, your combined knowledge of windows and CMake makes you the obvious candidate to ask Windows-related questions in an informed way on the CMake list. Therefore, would you please ask on that list whether there is a way for cmake to set up Windows builds to allow dll's to be found or is it a necessity to externally set the PATH? If a executable is run and a dll is needed, Windows looks first in the current directory for the dll. Then in the PATH. Then in c:\windows\system32 (and in some other system directories. Maybe PATH comes later, but this doesn't matter). Since we don't want to copy the dlls multiple times, our only chance is to change the PATH environment variable. I just read the cmake documentation about setting environment variables (http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set) and it should be possible to change the PATH variable that way. Presumably only as long as the Terminal window is open (so at least for the cmake configure stage). If you close the terminal, start it again this change is surely gone and I assume, if you then compile plplot (which is already configured) PATH won't be changed again, so you run into problems again. So this is no solution. I think you must be right. This is the issue (environment variable set in cmake not available for build) that I referred to based on my Linux experience with environment variables. Actually there are two problems. 1) plplot build is not finished, since testing the rc files fails, due to the missing dlls. I would suggest that for windows we force that the test-drv-info executable will be built into the dll folder (where for windows all dlls are gathered). Therefore the build gets through (since the dlls are in the same folder than test-drv-info). Please go ahead with that. 2) The examples don't run, since the dlls are not found. Now you need to either set the PATH variable or copy the dlls. User interaction is needed, the dlls are in the dll directory and the examples are in the examples directory, and this shouldn't be changed. So IMO the best we can do is, that in summary.cmake we add at the end a message (with many !) if it's a shared build on Windows and examples are built as well, the user is asked to add the dll directory to the PATH variable. Please go ahead with that. Also, please implement a similar message for the new CMake-based build system for the installed examples. See the summary message at the end of examples/CMakeLists.txt. I believe the most Windows developers know about what to do, if they run a program and a message box pops up telling him that the dll is missing. Still not perfect, but on the other hand it's not possible to cover everything. If the user wants to compile his own executables, he *must* take care of the dlls anyway. So if he doesn't RTFM it's best he gets into trouble trying to run the examples already. It would be more confusing if the examples run and his own programs not. Agreed. 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); PLplot scientific plotting software package (plplot.org); 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 __ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Fix AquaTerm header
On 11 February 2010 01:58, Hazen Babcock hbabc...@mac.com wrote: Leo wrote: Hello, The standard way to include a header file in a framework is [FRAMEWORK/HEADER], the following simple patch fixes this so that one no longer needs to set compiler flags in order to find the header file. Thanks, incorporated in v10801. Seems there's a typo. It should be AquaTerm/AQTAdapter.h. -Hazen Thanks. Leo -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plplot / Aquaterm / Snow Leopard problem
The user said that the xwin driver was ok, so maybe the xcairo driver will work as well? I believe the xwin driver does not use any libraries that ultimately depend on CoreFoundation, whereas the xcairo driver does. I expect that it will crash in the same way. I just installed xcairo and I can confirm it also crash with ? Trace/BPT trap error. Leo -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Fix AquaTerm header
Leo wrote: On 11 February 2010 01:58, Hazen Babcock hbabc...@mac.com wrote: Leo wrote: Hello, The standard way to include a header file in a framework is [FRAMEWORK/HEADER], the following simple patch fixes this so that one no longer needs to set compiler flags in order to find the header file. Thanks, incorporated in v10801. Seems there's a typo. It should be AquaTerm/AQTAdapter.h Sorry about that. Hopefully it is fixed in v10802. -Hazen -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Move definitions of pltr0f and pltr2f to plcont.c
David MacMahon wrote: Moves the definitions of pltr0f and pltr2f (both declared in plplot.h) from the sccont.c files of the FORTRAN bindings into plcont.c. Could you elaborate briefly on what problem this patch solves? thanks, -Hazen -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Move definitions of pltr0f and pltr2f to plcont.c
Hi, Hazen, On Feb 10, 2010, at 18:02 , Hazen Babcock wrote: David MacMahon wrote: Moves the definitions of pltr0f and pltr2f (both declared in plplot.h) from the sccont.c files of the FORTRAN bindings into plcont.c. Could you elaborate briefly on what problem this patch solves? It moves the definition (i.e. implementation) of these functions into libplotd so that programs that include plplot.h (which already contains the declaration of these functions) and use these functions will link successfully. It seems not so great to have functions declared in plplot.h without having a definition of them in the corresponding library. Try this... $ grep '^pltr' include/plplot.h pltr0( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr1( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr2( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr2p( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr0f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data ); pltr2f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data ); $ nm tmp/src/libplplotd.dylib | grep pltr d6cb T _pltr0 e2cd T _pltr0f d6e8 T _pltr1 d85c T _pltr2 e2ff T _pltr2f dda7 T _pltr2p I have this thread's patch applied so I see definitions in libplplotd for all six pltr* functions declared in plplot.h. If you do the same without this patch applied, you will only have four pltr* functions in libplplotd. An alternative fix would be to move the declarations from plplot.h into the FORTRAN bindings (where these functions were defined before this patch) . I wouldn't miss pltr0f if both its declaration and definition were in the FORTRAN bindings only, but I would very much miss pltr2f! Hope this clarifies things, Dave -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Move definitions of pltr0f and pltr2f to plcont.c
On 2010-02-10 21:57-0800 David MacMahon wrote: Hi, Hazen, On Feb 10, 2010, at 18:02 , Hazen Babcock wrote: David MacMahon wrote: Moves the definitions of pltr0f and pltr2f (both declared in plplot.h) from the sccont.c files of the FORTRAN bindings into plcont.c. Could you elaborate briefly on what problem this patch solves? It moves the definition (i.e. implementation) of these functions into libplotd so that programs that include plplot.h (which already contains the declaration of these functions) and use these functions will link successfully. It seems not so great to have functions declared in plplot.h without having a definition of them in the corresponding library. Try this... $ grep '^pltr' include/plplot.h pltr0( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr1( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr2( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr2p( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr0f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data ); pltr2f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data ); $ nm tmp/src/libplplotd.dylib | grep pltr d6cb T _pltr0 e2cd T _pltr0f d6e8 T _pltr1 d85c T _pltr2 e2ff T _pltr2f dda7 T _pltr2p I have this thread's patch applied so I see definitions in libplplotd for all six pltr* functions declared in plplot.h. If you do the same without this patch applied, you will only have four pltr* functions in libplplotd. An alternative fix would be to move the declarations from plplot.h into the FORTRAN bindings (where these functions were defined before this patch) . I wouldn't miss pltr0f if both its declaration and definition were in the FORTRAN bindings only, but I would very much miss pltr2f! Why? Do you have some non-Fortran use for it? I would prefer to keep definitions used in our Fortran bindings in sccont.c. But that assumes pltr0f and pltr2f will be used just for the Fortran bindings which is why I am asking the above 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); PLplot scientific plotting software package (plplot.org); 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 __ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plplot / Aquaterm / Snow Leopard problem
On 2010-02-11 02:20- Leo wrote: The user said that the xwin driver was ok, so maybe the xcairo driver will work as well? I believe the xwin driver does not use any libraries that ultimately depend on CoreFoundation, whereas the xcairo driver does. I expect that it will crash in the same way. I just installed xcairo and I can confirm it also crash with ? Trace/BPT trap error. Hi Leo: Is this a general problem which will always be seen (say if you run ctest or the test_noninteractive target) or a problem that only occurs for special circumstances? If it is special circumstances, than we should update our test suite (ctest and the test_noninteractive and test_interactive targets) to have at least one test which uses those circumstances. The rest of this post is directed to everybody on this list with access to Mac OS X. I strongly urge you to install both the pango/cairo development libraries and the Qt development libraries and do regular testing with the test_noninteractive (or ctest) and test_interactive targets for the svn/trunk version of PLplot. The combination of the cairo and qt device drivers produces excellent results for a large variety of noninteractive plot file formats and also for interactive plots so Mac OS X users are beginning to use those device drivers more and more. This recommended on-going testing effort is just to make sure that the majority of errors for our svn/trunk version and cairo and qt devices get discovered immediately on Mac OS X rather than much later by our Mac OS X users after we make a release. Leo mentioned in an earlier plplot-general thread that it was too time consuming to compile Qt on Mac OS X. However, I don't believe compilation is required in this case. According to http://qt.nokia.com/downloads, there is an SDK version available for Mac OS X. When I tried the corresponding Linux 64-bit SDK, it was a binary with no need to build so I presume that is also true of the Mac OS X SDK. If Leo or anybody else here will confirm that, I will go back and respond to that earlier thread on plplot-general so our Mac OS X users don't get unnecessarily intimidated about installing Qt. You do need lots of disk space for the SDK downloads and the corresponding installed libraries and uncompressed data associated with those libraries. But that is typically less disk space than the 2GB used to store the plots that are produced with make test_noninteractive. Hopefully none of those lurking on this list are squeezed for disk space in any case since you can buy 500GB to 1000GB of additional disk space now for ridiculously small cost. 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); PLplot scientific plotting software package (plplot.org); 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 __ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
