Re: [Plplot-devel] 5.8.0 Release?
On Fri, Nov 16, 2007 at 10:36:35AM -0800, Alan Irwin wrote: I was just able to do some more testing of PLplot, and I found some excessive java warnings for the examples build in both the build tree and install tree for the gij/gcj case. Here is one of the typical warnings you see with -DBUILD_TEST=ON in make.out /home/software/plplot_cvs/HEAD/plplot_cmake/examples/java/x01.java:66: warning: The static field plplotjavacConstants.PL_PARSE_FULL should be accessed directly /home/software/plplot_cvs/HEAD/plplot_cmake/examples/java/x01.java:66: warning: The static field plplotjavacConstants.PL_PARSE_NOPROGRAM should be accessed directly 2 problems (2 warnings) These type of warnings appear for all examples. Andrew, this is obviously not release critical since they are just warnings, but if there is a small change you could do to get rid of these, it might be worth doing before the release. Urgh. Sometimes gcj / gij is just rather pedantic when it comes to warning messages. I think this is one of them. The solution would be to use e.g. plplotjavacConstants.PL_PARSE_FULL rather than PLStream.PL_PARSE_FULL to access constants. PLStream inherits the interface plplotjavacConstants where the constants are designed. I could see the point for static variables (i.e. those where there is one variable shared across all instances of the class) where you want to be explicit which parent class the variable belongs to. For interfaces (like plplotjavaConstant) where all static variables are final (i.e. constants) then this seems pointless. It also means you can't use this trick to define inherited constants in your own classes. The whole point of PLStream is to hide all the swig details and so I'd really rather not change the examples. I'll see if there is another way around the problem. By the way a quick search on google suggests that eclipse may also have a similar warning. Andrew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
In contrast, your octave version is reasonable consistent with the one I tested successfully on Debian testing. [EMAIL PROTECTED] octave --version GNU Octave, version 2.1.73 (x86_64-pc-linux-gnu). Andrew, is there any chance of quickly tracking down the source of the many octave errors above for the Mac OS X version of octave 2.1.73? Normally, I am pretty picky about fixing bugs before release, but a lot of effort has already been put in doing just that for this 5.8.0 release. Thus, even I can see we may have reached the point where it's expedient to release with known bugs so we can get on with a number of interesting projects that have been put off until just after 5.8.0 comes out. So if there are no reasonably easy fixes to one or both of the above issues, my vote would be to note the issues in the release notes for 5.8.0 (i.e., publicly write off gfortran 4.2.0 and/or octave 2.1.73 for Mac OS X), and get 5.8.0 out the door. Let me know the prospects for straightforward fixes for the above two problems, and in the absence of those whether you agree we should just go ahead with the 5.8.0 release. This is odd. 2.1.73 has been extensively tested as it has been the stable version for some time. Hazen, did the octave bindings used to work for you? Do you know when the change occured? It is interesting the error occurs in plstyl. There were problems with this (it didn't accept null strings), but I patched matwrap in plplot to fix this back in June. Are you sure you have a completely clean tree and are not picking up old versions of the library? Could you test with an old version of plplot before those changes to see if that is the cause of the error? I tried 5.7.0 - 5.7.4 but none of them would even build the octave bindings. This is a little puzzling because I think that I did have it working at one point, thus the note on the wiki about Octave working (before I changed the wiki just now). -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
To Andrew and Hazen: With your recent work on Java it looks like there are now only two remaining release critical issues (both for Mac OS X). Here is Hazen's excerpted old message about those issues from when they were still fresh in his mind: On 2007-11-02 23:32-0400 Hazen Babcock wrote: ./plplot-test.sh was somewhat less succesful. [snip] Testing front-end f95 PLplot library version: 5.8.0-RC1 *** PLPLOT ERROR, ABORTING OPERATION *** UTF-8 string is malformed: UTF-8 st, aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** UTF-8 string is malformed: UTF-8 stri, aborting operation [...] Testing front-end octave /usr/local/share/plplot5.8.0-RC1/examples/.. *** plstyl: plstyl(mark, space) Set up a new line style Additional help for built-in functions, operators, and variables is available in the on-line version of the manual. Use the command `help -i topic' to search the manual index. Help and information about Octave is also available on the WWW at http://www.octave.org and via the [EMAIL PROTECTED] mailing list. error: called from `plsstrm' error: evaluating if command near line 86, column 3 error: called from `figure' in file `/usr/local/share/plplot_octave/figure.m' error: evaluating for command near line 4, column 1 It looks like there are problems with F95 [...] and octave. Version information: gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060512 (experimental) octave -version GNU Octave, version 2.1.73 (powerpc-apple-darwin7.9.0). Copyright (C) 2006 John W. Eaton. The Debian testing version (which works well for PLplot) is [EMAIL PROTECTED] gfortran --version GNU Fortran (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) It appears the Debian version is 17 months later which is a long time in the gfortran world. Hazen, perhaps a prerelease version of 4.2.3 is a bit much to ask, but could you install, say, version 4.2.1 or 4.2.2? That might cure the utf-8 string problems your gfortran compiler detects in every example (which are mostly all ascii, by the way). For comparison, I don't see this (on i386) with Ubuntu edgy GNU Fortran 95 (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) or on Ubuntu gutsy with GNU Fortran (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) so it looks like this is either a problem just with 4.2.0 or it is a OS-X specific issue. Given it is utf8 string handling it could be either really. In contrast, your octave version is reasonable consistent with the one I tested successfully on Debian testing. [EMAIL PROTECTED] octave --version GNU Octave, version 2.1.73 (x86_64-pc-linux-gnu). Andrew, is there any chance of quickly tracking down the source of the many octave errors above for the Mac OS X version of octave 2.1.73? Normally, I am pretty picky about fixing bugs before release, but a lot of effort has already been put in doing just that for this 5.8.0 release. Thus, even I can see we may have reached the point where it's expedient to release with known bugs so we can get on with a number of interesting projects that have been put off until just after 5.8.0 comes out. So if there are no reasonably easy fixes to one or both of the above issues, my vote would be to note the issues in the release notes for 5.8.0 (i.e., publicly write off gfortran 4.2.0 and/or octave 2.1.73 for Mac OS X), and get 5.8.0 out the door. Let me know the prospects for straightforward fixes for the above two problems, and in the absence of those whether you agree we should just go ahead with the 5.8.0 release. This is odd. 2.1.73 has been extensively tested as it has been the stable version for some time. Hazen, did the octave bindings used to work for you? Do you know when the change occured? It is interesting the error occurs in plstyl. There were problems with this (it didn't accept null strings), but I patched matwrap in plplot to fix this back in June. Are you sure you have a completely clean tree and are not picking up old versions of the library? Could you test with an old version of plplot before those changes to see if that is the cause of the error? Andrew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
I was just able to do some more testing of PLplot, and I found some excessive java warnings for the examples build in both the build tree and install tree for the gij/gcj case. Here is one of the typical warnings you see with -DBUILD_TEST=ON in make.out /home/software/plplot_cvs/HEAD/plplot_cmake/examples/java/x01.java:66: warning: The static field plplotjavacConstants.PL_PARSE_FULL should be accessed directly /home/software/plplot_cvs/HEAD/plplot_cmake/examples/java/x01.java:66: warning: The static field plplotjavacConstants.PL_PARSE_NOPROGRAM should be accessed directly 2 problems (2 warnings) These type of warnings appear for all examples. Andrew, this is obviously not release critical since they are just warnings, but if there is a small change you could do to get rid of these, it might be worth doing before the release. 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 __ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
On 2007-11-16 21:08-0500 Hazen Babcock wrote: I installed gfortran 4.2.1 and it seems to have fixed whatever was causing this problem [the Mac OS X string issues with gfortran 4.2.0]. That is excellent news, Hazen. gfortran 4.2.0 might well have the same issue on Linux (if any distro still installs that version) so I think the whole topic can be covered off by you making a one-liner in the release notes to suggest using gfortran 4.2.1 or later. So that leaves only the Mac OS X octave issue as our last potential release blocker, but I think you can cover that off as well by a short sentence in the release notes since nobody understands why that Octave version quit working (There is a note in our wiki that Octave worked before on Mac OS X.) Anyhow, I think there is good potential here to get 5.8.0 released as early as this weekend with some luck. What do you think of this possibility? 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 __ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
To Andrew and Hazen: With your recent work on Java it looks like there are now only two remaining release critical issues (both for Mac OS X). Here is Hazen's excerpted old message about those issues from when they were still fresh in his mind: On 2007-11-02 23:32-0400 Hazen Babcock wrote: ./plplot-test.sh was somewhat less succesful. [snip] Testing front-end f95 PLplot library version: 5.8.0-RC1 *** PLPLOT ERROR, ABORTING OPERATION *** UTF-8 string is malformed: UTF-8 st, aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** UTF-8 string is malformed: UTF-8 stri, aborting operation [...] Testing front-end octave /usr/local/share/plplot5.8.0-RC1/examples/.. *** plstyl: plstyl(mark, space) Set up a new line style Additional help for built-in functions, operators, and variables is available in the on-line version of the manual. Use the command `help -i topic' to search the manual index. Help and information about Octave is also available on the WWW at http://www.octave.org and via the [EMAIL PROTECTED] mailing list. error: called from `plsstrm' error: evaluating if command near line 86, column 3 error: called from `figure' in file `/usr/local/share/plplot_octave/figure.m' error: evaluating for command near line 4, column 1 It looks like there are problems with F95 [...] and octave. Version information: gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060512 (experimental) octave -version GNU Octave, version 2.1.73 (powerpc-apple-darwin7.9.0). Copyright (C) 2006 John W. Eaton. The Debian testing version (which works well for PLplot) is [EMAIL PROTECTED] gfortran --version GNU Fortran (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) It appears the Debian version is 17 months later which is a long time in the gfortran world. Hazen, perhaps a prerelease version of 4.2.3 is a bit much to ask, but could you install, say, version 4.2.1 or 4.2.2? That might cure the utf-8 string problems your gfortran compiler detects in every example (which are mostly all ascii, by the way). In contrast, your octave version is reasonable consistent with the one I tested successfully on Debian testing. [EMAIL PROTECTED] octave --version GNU Octave, version 2.1.73 (x86_64-pc-linux-gnu). Andrew, is there any chance of quickly tracking down the source of the many octave errors above for the Mac OS X version of octave 2.1.73? Normally, I am pretty picky about fixing bugs before release, but a lot of effort has already been put in doing just that for this 5.8.0 release. Thus, even I can see we may have reached the point where it's expedient to release with known bugs so we can get on with a number of interesting projects that have been put off until just after 5.8.0 comes out. So if there are no reasonably easy fixes to one or both of the above issues, my vote would be to note the issues in the release notes for 5.8.0 (i.e., publicly write off gfortran 4.2.0 and/or octave 2.1.73 for Mac OS X), and get 5.8.0 out the door. Let me know the prospects for straightforward fixes for the above two problems, and in the absence of those whether you agree we should just go ahead with the 5.8.0 release. 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 __ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
Alan W. Irwin wrote: On 2007-11-02 19:40-0400 Hazen Babcock wrote: Hello, What is the current thinking on the 5.8.0 final release? Are there still Cygwin issues that need to be sorted out or are we ready? From what I have read, I believe we are ready (at least as good as before and very likely much better) on Cygwin, but I am a little uneasy about the complete lack of reported platform testing of the changes that have been made since 5.8.0-RC1. Has anybody done a Linux or Mac OS X test of the latest svn trunk? Builds and tests run fine for me on Fedora Development. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
Alan W. Irwin writes: Geoffrey asked: So I guess the question is, how can I make find_package(PythonInterp) find the python that's in the prefix, instead of the one that's in the path? Try changing PATH so the special python is what you get when you execute the python command. PATH is mentioned along with a few other important environment variables that may need to be set under the heading (Optional) set environment variables to help cmake find system components that are installed in non-standard locations in our wiki. So, if I set my path to have $(PREFIX)/bin before /usr/bin, then the correct python is found and used during cmake processing. I still think that find_package(PythonInterp) should look in prefix/bin first, then fall back to system path. If someone has put something for which they're trying to build plplot support, into the prefix, then they surely want that one to be the one used by the plplot build system. So, if anyone could suggest to me how to change this behavior of cmake, I would be interested to play with it a bit and see if I can follow the advice and make it work more sensibly. Be that as it may, I have a new and more serious problem. When I try to build plplot after running cmake as explained in my first post, the build fails while trying to build the python binding. [ 26%] Building C object bindings/python/CMakeFiles/_plplotcmodule.dir/plplotcmodulePYTHON_wrap.o /home/furnish/icfdev/prefix-icf/plplot/tmp2/bindings/python/plplotcmodulePYTHON_wrap.c:2510:1: warning: PySequence_Fast_GET_ITEM redefined In file included from /home/furnish/prefix/icf2/include/python2.5/Python.h:126, from /home/furnish/icfdev/prefix-icf/plplot/tmp2/bindings/python/plplotcmodulePYTHON_wrap.c:112: /home/furnish/prefix/icf2/include/python2.5/abstract.h:1059:1: warning: this is the location of the previous definition Linking C shared module _plplotcmodule.so /usr/bin/ld: /home/furnish/prefix/icf2/lib/python2.5/config/libpython2.5.a(abstract.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /home/furnish/prefix/icf2/lib/python2.5/config/libpython2.5.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [bindings/python/_plplotcmodule.so] Error 1 make[1]: *** [bindings/python/CMakeFiles/_plplotcmodule.dir/all] Error 2 make: *** [all] Error 2 What I have learned is that on Fedora 7, the python that's on the system has: % ll /usr/lib64/python2.5/config/libpython2.5.so lrwxrwxrwx 1 root root 21 2007-08-30 17:46 /usr/lib64/python2.5/config/libpython2.5.so - ../../libpython2.5.so But, when I build python myself and install to a custom prefix, the libpython2.5.so never shows up under $prefix/lib/python2.5/config. I only get the .a. I have tried building python with --enable-shared, and that just doesn't work/help. Two things about that: 1) Although libpython2.5.so does get built in the python build dir, it doesn't get installed. 2) The python that winds up in the prefix doesn't seem to be linked properly, so sys.path winds up pointing to /usr/lib64/*, instead of to $prefix/lib/*. This makes the resulting python very wonky. So, I've given up on configuring python --enable-shared, and am just going with a default build/install of python, which seems to work normally enough as far as I can tell. sys.path is rooted at $prefix/lib, and plenty of the auto-configured dynloadable modules work just fine (like import Tkinter). So, back to building plplot. Unfortunately, somehow, the cmake system thinks it need sto link to python2.5 when buiding a dynloadable _plplotcmodule.so, and so it winds up with a file under the build dir: bindings/python/CMakeFiles/_plplotcmodule.dir/relink.txt which contains a command for building the _plplotcmodule.so, and this command includes -L$prefix/lib/python2.5/config -lpython2.5, which is what triggers the above error, since the only thing there is libpython2.5.a. I have found that if I take out explicit reference to -lpython2.5, then _plplotcmodule.so, just like all the dynloadable modules that are built by the python build process itself, will link just fine. So, question: Can anyone help me understnad how bindings/python/CMakeFiles/_plplotcmodule.dir/relink.txt is generated, and suggest how I might fix it's generation to not name the unnecessary and trouble-causing -lpython2.5? Thanks much. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
On 2007-11-02 19:40-0400 Hazen Babcock wrote: Hello, What is the current thinking on the 5.8.0 final release? Are there still Cygwin issues that need to be sorted out or are we ready? From what I have read, I believe we are ready (at least as good as before and very likely much better) on Cygwin, but I am a little uneasy about the complete lack of reported platform testing of the changes that have been made since 5.8.0-RC1. Has anybody done a Linux or Mac OS X test of the latest svn trunk? Reports of MinGW (with and without MSYS) and bare windows tests would be nice as well. Currently, I am tied up with installing a Debian testing distro on my new computer so unfortunately I cannot lead by example here by giving any Linux reports, but hopefully a lot of you will step in with your own reports to make up for that. 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 __ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
On Nov 2, 2007, at 10:13 PM, Alan W. Irwin wrote: From what I have read, I believe we are ready (at least as good as before and very likely much better) on Cygwin, but I am a little uneasy about the complete lack of reported platform testing of the changes that have been made since 5.8.0-RC1. Has anybody done a Linux or Mac OS X test of the latest svn trunk? Reports of MinGW (with and without MSYS) and bare windows tests would be nice as well. Currently, I am tied up with installing a Debian testing distro on my new computer so unfortunately I cannot lead by example here by giving any Linux reports, but hopefully a lot of you will step in with your own reports to make up for that. You inspired me to do some OS-X testing. It seems to build fine. Running ./plplot-test.sh was somewhat less succesful. [snip] Testing front-end f95 PLplot library version: 5.8.0-RC1 *** PLPLOT ERROR, ABORTING OPERATION *** UTF-8 string is malformed: UTF-8 st, aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** UTF-8 string is malformed: UTF-8 stri, aborting operation Testing front-end java Unable to find native code library. Testing front-end octave /usr/local/share/plplot5.8.0-RC1/examples/.. *** plstyl: plstyl(mark, space) Set up a new line style Additional help for built-in functions, operators, and variables is available in the on-line version of the manual. Use the command `help -i topic' to search the manual index. Help and information about Octave is also available on the WWW at http://www.octave.org and via the [EMAIL PROTECTED] mailing list. error: called from `plsstrm' error: evaluating if command near line 86, column 3 error: called from `figure' in file `/usr/local/share/plplot_octave/ figure.m' error: evaluating for command near line 4, column 1 It looks like there are problems with F95, java and octave. Version information: gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060512 (experimental) java -version java version 1.5.0_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) octave -version GNU Octave, version 2.1.73 (powerpc-apple-darwin7.9.0). Copyright (C) 2006 John W. Eaton. -Hazen - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.8.0 Release?
Geoffrey, your attached message bounced for some reason. Did you
mail it with the same return address as your subscription address?
Anyhow, I am forwarding it to the list for you.
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
__---BeginMessage---
Alan W. Irwin writes:
Has anybody done a Linux or Mac OS X test of the latest svn trunk?
I'm working on Fedora 7. I have a fairly fresh checkout (1 or 2 days old),
and am having some trouble with getting the python binding working. Could be
operator error or confusion here, but anyway, these are the details.
python 2.5.1 configured/installed to a particular --prefix location, where
Tcl, Tk are also installed.
I have further fetched the latest numpy (1.0.3.1) and built/installed it
using that same python. If I run that python executable, I get:
% ./bin/python
Python 2.5.1 (r251:54863, Nov 2 2007, 09:24:57)
[GCC 4.1.2 20070502 (Red Hat 4.1.2-12)] on linux2
Type help, copyright, credits or license for more information.
import numpy
numpy.test()
Found 10 tests for numpy.core.defmatrix
Found 36 tests for numpy.core.ma
Found 208 tests for numpy.core.multiarray
...
So, python is built, numpy is built/installed to the same python, and numpy
can be found.
But, when I try to build plplot, the CBS tells me:
-- X11_FOUND = 1
-- X11_INCLUDE_DIR = /usr/include
-- X11_COMPILE_FLAGS = -I/usr/include
-- X11_LIBRARIES = -lSM;-lICE;/usr/lib64/libX11.so;/usr/lib64/libXext.so
-- X11_LIBRARY_DIR = /usr/lib64
Traceback (most recent call last):
File string, line 1, in module
ImportError: No module named numpy
-- WARNING: Numeric header not found. Disabling python bindings
-- WARNING: octave not found. Disabling octave bindings
-- Looking for include paths and libraries for Tcl/Tk
-- Looking for include paths and libraries for Tcl/Tk - found
The subsequent lines show that it is finding Tcl/Tk from the prefix zone, as
it should. So it's definitely finding some things in the
prefix-under-construction.
But python/numpy isn't being recognized for some reason.
It seems to me that python.cmake must be somehow coming up with the wrong
path:
if(ENABLE_python AND NOT NUMERIC_INCLUDE_PATH)
if (HAVE_NUMPY)
# First check for new version of numpy (replaces Numeric)
execute_process(
COMMAND
${PYTHON_EXECUTABLE} -c import numpy; print numpy.get_include()
OUTPUT_VARIABLE NUMPY_INCLUDE_PATH
RESULT_VARIABLE NUMPY_ERR
OUTPUT_STRIP_TRAILING_WHITESPACE
)
Because when I issue that command to the prefix's python, it works fine.
So, I guess a basic question is, how could I modify python.cmake to print out
the PYTHON_EXECUTABLE it found, so I could check that theory?
Ahhh. I have found in CMakeCache.txt:
//Path to a program.
PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2.5
which is not the python in the prefix zone that I want it to use. The
subsequent lines show that the includes and libs are being found in my
prefix, but the executable is not.
The prefix under construction is not on my path. But that doesn't seem to
prevent PLplot's CBS from finding the right Tcl and Tk. So I guess the
question is, how can I make find_package(PythonInterp) find the python
that's in the prefix, instead of the one that's in the path?
Thanks in advance,
--
Geoffrey Furnish Lightspeed Logic
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
- Brian W. Kernighan
---End Message---
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
