From: <f.d...@at...> - 2004-03-17 11:14:50
|
Hi, I was trying to build plplot on OS X 10.3 (panther) with its *native* python-2.3 (not a fink version, like Koen van der Drift seems to be using (maybe he is on 10.2.x?)) OS X 10.3 python is a "Framework", not a Dylib, and has no libpython.* so configure fails. 10.3 is the first OS X wth a native python, I beleieve. Python is in /System/Library/Frameworks/Python.framework/Versions/2.3 The *.pu, *.pyo, *.pyc files are in .../Versions/2.3/lib/python2.3/ The include files are in .../Versions/2.3/include/python2.3 = $PYTHON_INC_DIR, I guess. There is no Numeric in this directory. obviously PYTHON_VERSION=2.3 any ideas what PYTHON_LDFLAGS should be? Duncan |
From: Per P. <per...@ma...> - 2004-03-17 11:37:29
|
On 2004-03-17, at 12.14, f.d...@at... wrote: > Hi, > > any ideas what PYTHON_LDFLAGS should be? A guess: -framework Python /Per |
From: Alan W. I. <ir...@be...> - 2004-03-17 16:33:43
|
On 2004-03-17 11:14-0000 f.d...@at... wrote: > Hi, > > I was trying to build plplot on OS X 10.3 (panther) with > its *native* python-2.3 (not a fink version, like Koen van > der Drift seems to be using (maybe he is on 10.2.x?)) > > > OS X 10.3 python is a "Framework", not a Dylib, and has no > libpython.* so configure fails. None of the core developers here have first-hand experience with Mac OS X, but we are gradually learning from what is said here. So could you please explain the general difference between a Framework and Dylib for our general education? Also, it sounds like we will have to modify the search for libpython.*. What is the path+name of the corresponding native Python Framework? It's possible the Fink Python has the "framework" form of the python library as well, in which case we should just search for and link to it for all Mac OS X cases. Koen, could you find out whether fink Python has a framework version of the python library available, and if so, what is its full path+name? > > 10.3 is the first OS X wth a native python, I beleieve. > > Python is in > /System/Library/Frameworks/Python.framework/Versions/2.3 > > > > The *.pu, *.pyo, *.pyc files are in > .../Versions/2.3/lib/python2.3/ > > > > The include files are in > .../Versions/2.3/include/python2.3 = $PYTHON_INC_DIR, > I guess. > > There is no Numeric in this directory. Numeric (also known as numpy, see http://www.pfdubois.com/numpy/) is essential. So you will be forced to use the Fink Numeric=numpy and therefore (I assume) the Fink python unless you download and build numpy yourself. Assuming you want to take that additional step, the numpy version you should be using is typically 10 times the python version. So PYTHON_VERSION=2.3 implies you should be using numpy version 23.1, see http://sourceforge.net/projects/numpy for how to download it. > > > obviously PYTHON_VERSION=2.3 > > any ideas what PYTHON_LDFLAGS should be? libtool was generating linking instructions appropriate to a framework (I now believe) which were of course inappropriate for the Dylib that was found in the fink case. This caused a run-time error. We found a workaround was just to drop this part of the link altogether. Currently, this should happen automatically for your platform (check the extra_ldflags = -no-undefined $(PYTHON_LDFLAGS) line in bindings/Makefile to see whether it has been commented out by the configuration process). So currently you can specify anything for PYTHON_LDFLAGS, and it will be ignored. But this is just a fink workaround, and I hope you drop the commenting out and do further experimentation to find out the correct PYTHON_LDFLAGS for the framework case in hopes we can adopt it for both native and fink python. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-03-17 22:20:40
|
On Mar 17, 2004, at 11:31 AM, Alan W. Irwin wrote: > Koen, could you find out whether fink Python has a framework version > of the python library available, and if so, what is its full path+name? > On my system (10.3.3), the is a symbolic link in /usr/bin/python2.3 that points to /System/Library/Frameworks/Python.framework/Versions/2.3/bin/python. in /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ are all the library related files. hth, - Koen. |
From: Alan W. I. <ir...@be...> - 2004-03-18 02:03:21
|
On 2004-03-17 17:20-0500 Koen van der Drift wrote: > > On Mar 17, 2004, at 11:31 AM, Alan W. Irwin wrote: > > > Koen, could you find out whether fink Python has a framework version > > of the python library available, and if so, what is its full path+name? > > > > On my system (10.3.3), the is a symbolic link in /usr/bin/python2.3 > that points to > /System/Library/Frameworks/Python.framework/Versions/2.3/bin/python. > in > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ > are all the library related files. You have given me a symbolic link to what looks to be an executable, and that may not (or may, I don't know) be what is required here. Perhaps I need to be educated about what a "framework" is? What is really going on is when UNDERSCORE_plplotcmodule.extension (which on install is renamed to _plplotcmodule.extension and which is a dynamically loadable shared object which wraps the PLplot API in libplplot for python) is created it has references to symbols such as PyArg_ParseTuple. On the two other systems where we have python working (Linux and Cygwin) those symbols are resolved at link time by linking in the python shared library libpython.so. But currently we cannot do this on Mac OS X without running into run-time troubles (unable to dynamically load _plplotcmodule.extension using the import _plplotc command from python). We have a workaround (resolve the symbols at run-time, a method which does not work on Cygwin), but I would like to learn how to resolve the symbols at link time on Mac OS X just like I do now for Linux and Cygwin. Now Per in separate e-mail suggested using -framework Python, and as I recall before we disabled it, libtool was trying to use the -framework command on your system, but probably with the wrong file. So identifying the correct framework file is essential. Do you think the symlink you reported above is it? Whatever that framework file is named, nm (or the Mac OS X equivalent) should show PyArg_ParseTuple is defined in that file. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-03-18 03:14:10
|
On Mar 17, 2004, at 9:03 PM, Alan W. Irwin wrote: > You have given me a symbolic link to what looks to be an executable, > and > that may not (or may, I don't know) be what is required here. Perhaps > I > need to be educated about what a "framework" is? I believe a Framework in Mac OS X is a collection of headers, libraries and executables all in different directories, but in one enclosing directory, in this case called Python.framework. Different version can reside in the framework, on my machine it is only 2.3 that came with Mac OS X. So, if I look what's in the 2.3 directory, I get: RubyTuesday:/System/Library/Frameworks/Python.framework/Versions/2.3 koen$ la total 2136 drwxr-xr-x 9 root wheel 306 17 Mar 18:47 . drwxr-xr-x 4 root wheel 136 13 Sep 2003 .. lrwxr-xr-x 1 root wheel 17 5 Nov 15:42 Headers -> include/python2.3 drwxr-xr-x 3 root wheel 102 27 Sep 05:39 Mac -rwxr-xr-x 1 root wheel 1088276 17 Mar 18:47 Python drwxr-xr-x 7 root wheel 238 27 Sep 05:39 Resources drwxr-xr-x 6 root wheel 204 17 Mar 18:48 bin drwxr-xr-x 3 root wheel 102 27 Sep 05:38 include > Now Per in separate e-mail suggested using -framework Python, and as I > recall > before we disabled it, libtool was trying to use the -framework > command on > your system, but probably with the wrong file. So identifying the > correct > framework file is essential. Do you think the symlink you reported > above > is it? Whatever that framework file is named, nm (or the Mac OS X > equivalent) > should show PyArg_ParseTuple is defined in that file. The standard installed Python has no libpython.so file, but the fink version has a libpython2.3.dylib that resides in /sw/lib/python2.3/config/. The contents of the corresponding directory in the framework are: RubyTuesday:/System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/config koen$ la total 184 drwxr-xr-x 11 root wheel 374 27 Sep 05:38 . drwxr-xr-x 578 root wheel 19652 13 Sep 2003 .. -rw-r--r-- 1 root wheel 35873 13 Sep 2003 Makefile -rw-r--r-- 1 root wheel 17821 13 Sep 2003 Setup -rw-r--r-- 1 root wheel 368 13 Sep 2003 Setup.config -rw-r--r-- 1 root wheel 41 13 Sep 2003 Setup.local -rw-r--r-- 1 root wheel 1810 13 Sep 2003 config.c -rw-r--r-- 1 root wheel 1191 13 Sep 2003 config.c.in -rwxr-xr-x 1 root wheel 7122 13 Sep 2003 install-sh -rwxr-xr-x 1 root wheel 7430 13 Sep 2003 makesetup -rw-r--r-- 1 root wheel 636 13 Sep 2003 python.o - Koen. |
From: Koen v. d. D. <kvd...@ea...> - 2004-03-18 03:35:05
|
On Mar 17, 2004, at 10:14 PM, Koen van der Drift wrote: > RubyTuesday:/System/Library/Frameworks/Python.framework/Versions/2.3 > koen$ la > total 2136 > drwxr-xr-x 9 root wheel 306 17 Mar 18:47 . > drwxr-xr-x 4 root wheel 136 13 Sep 2003 .. > lrwxr-xr-x 1 root wheel 17 5 Nov 15:42 Headers -> > include/python2.3 > drwxr-xr-x 3 root wheel 102 27 Sep 05:39 Mac > -rwxr-xr-x 1 root wheel 1088276 17 Mar 18:47 Python > drwxr-xr-x 7 root wheel 238 27 Sep 05:39 Resources > drwxr-xr-x 6 root wheel 204 17 Mar 18:48 bin > drwxr-xr-x 3 root wheel 102 27 Sep 05:38 include An addition, the file 'Python' above is the dynamic shared library: RubyTuesday:/System/Library/Frameworks/Python.framework koen$ file -L Python Python: Mach-O dynamically linked shared library ppc The command 'nm _PyArg_ParseTuple Python' gives a long list, but a few lines are: Python(getargs.o): 95fba60c T _PyArg_Parse 95fba640 T _PyArg_ParseTuple 95fbc478 T _PyArg_ParseTupleAndKeywords 95fbcde4 T _PyArg_UnpackTuple 95fba674 T _PyArg_VaParse hth, - Koen. |
From: Alan W. I. <ir...@be...> - 2004-03-18 05:36:35
|
On 2004-03-17 22:34-0500 Koen van der Drift wrote: > > On Mar 17, 2004, at 10:14 PM, Koen van der Drift wrote: > > > RubyTuesday:/System/Library/Frameworks/Python.framework/Versions/2.3 > > koen$ la > > total 2136 > > drwxr-xr-x 9 root wheel 306 17 Mar 18:47 . > > drwxr-xr-x 4 root wheel 136 13 Sep 2003 .. > > lrwxr-xr-x 1 root wheel 17 5 Nov 15:42 Headers -> > > include/python2.3 > > drwxr-xr-x 3 root wheel 102 27 Sep 05:39 Mac > > -rwxr-xr-x 1 root wheel 1088276 17 Mar 18:47 Python > > drwxr-xr-x 7 root wheel 238 27 Sep 05:39 Resources > > drwxr-xr-x 6 root wheel 204 17 Mar 18:48 bin > > drwxr-xr-x 3 root wheel 102 27 Sep 05:38 include > > An addition, the file 'Python' above is the dynamic shared library: > > RubyTuesday:/System/Library/Frameworks/Python.framework koen$ file -L > Python > Python: Mach-O dynamically linked shared library ppc > > The command 'nm _PyArg_ParseTuple Python' gives a long list, but a few > lines are: > > Python(getargs.o): > 95fba60c T _PyArg_Parse > 95fba640 T _PyArg_ParseTuple > 95fbc478 T _PyArg_ParseTupleAndKeywords > 95fbcde4 T _PyArg_UnpackTuple > 95fba674 T _PyArg_VaParse That Python file caught my eye as well (and the original message that started this thread mentioned it as well, although I misinterpreted that reference to be referring to the Python language itself rather than a dynamically linked shared library). That file indeed seems to supply all the needed symbols, but now that I have thought a bit more about it, I think linking against that native python library doesn't make sense since presumably it is not exactly compatible with the fink python. I am now wondering if you had trouble before at run-time when linked against the fink version of libpython because you were executing the native version of python rather than the fink version? On linux 'which python' would tell you which (native or fink) python executable you are using when you execute python. Another question is whether there is some equivalent of the above Python file in the /sw tree that is generated by fink? In other words does fink have a python framework? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-03-18 08:55:03
|
On Mar 18, 2004, at 12:33 AM, Alan W. Irwin wrote: > I am now wondering if you had trouble before at run-time when linked > against > the fink version of libpython because you were executing the native > version > of python rather than the fink version? Never tried that :) > Another question is whether there is some equivalent of the above > Python > file in the /sw tree that is generated by fink? In other words does > fink > have a python framework? No, I don't think so. Frameworks are typical for Mac OS X, fink treats packages more as unix in general (whatever that means). I found this page which might clarify things for you: http://www.kernelthread.com/mac/osx/programming.html - Koen. |
From: Koen v. d. D. <kvd...@ea...> - 2004-03-18 23:32:02
|
On Mar 18, 2004, at 3:54 AM, Koen van der Drift wrote: >> I am now wondering if you had trouble before at run-time when linked >> against >> the fink version of libpython because you were executing the native >> version >> of python rather than the fink version? > > Never tried that :) > > It was waaaay to early when I wrote that, now I see what you were actually asking. Yes, I had some problems because I failed to install the fink package for 'python', a versionless symbolic link to the correct python2.3 in /sw. I don't remember if I was executing /usr/bin/python in that case, it should be in the mailing list archives. The only part that fink doesn't provide is java, so that's the only Mac OS X framework that plplot uses. - Koen. |
From: Alan W. I. <ir...@be...> - 2004-03-18 23:58:32
|
On 2004-03-18 18:31-0500 Koen van der Drift wrote: > > On Mar 18, 2004, at 3:54 AM, Koen van der Drift wrote: > > >> I am now wondering if you had trouble before at run-time when linked > >> against > >> the fink version of libpython because you were executing the native > >> version > >> of python rather than the fink version? > > > > Never tried that :) > > > > > > It was waaaay to early when I wrote that, now I see what you were > actually asking. Yes, I had some problems because I failed to install > the fink package for 'python', a versionless symbolic link to the > correct python2.3 in /sw. I don't remember if I was executing > /usr/bin/python in that case, it should be in the mailing list > archives. The only part that fink doesn't provide is java, so that's > the only Mac OS X framework that plplot uses. If you want to re-try the experiment, then build as you normally do ending with the "make" command in the top-level directory. Then cd bindings/python edit Makefile so that extra_ldflags = -no-undefined $(PYTHON_LDFLAGS) is not commented out. Clean out the old build in bindings/python make clean Rebuild with the modified Makefile make Then cd back to the top-level directory and install cd ../.. make install Then try the installed examples to see if python (the fink version, not the native version) works. (Use "which python" to see whether you get the fink or native versions.) In the old days, the build and install worked fine, but python could not import _plplotc. However, you may have been using the native version of python rather than the fink version. Anyhow, this test is worth a shot. I have never understood why python could not import _plplotc when that was linked properly to libpython (just as for Linux and Cygwin), and the only thing I can think of is some inconsistency (such as between fink and native python). Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-03-19 00:19:20
|
On Mar 18, 2004, at 6:51 PM, Alan W. Irwin wrote: > Then try the installed examples to see if python (the fink version, > not the > native version) works. (Use "which python" to see whether you get the > fink > or native versions.) In the old days, the build and install worked > fine, but > python could not import _plplotc. However, you may have been using the > native version of python rather than the fink version. > I am not sure what the purpose of this exercise is. Why would a user of fink want to use the native python version, while fink provides a more up-to-date version? - Koen. |
From: Alan W. I. <ir...@be...> - 2004-03-19 02:12:18
|
On 2004-03-18 19:19-0500 Koen van der Drift wrote: > > On Mar 18, 2004, at 6:51 PM, Alan W. Irwin wrote: > > > Then try the installed examples to see if python (the fink version, > > not the > > native version) works. (Use "which python" to see whether you get the > > fink > > or native versions.) In the old days, the build and install worked > > fine, but > > python could not import _plplotc. However, you may have been using the > > native version of python rather than the fink version. > > > > I am not sure what the purpose of this exercise is. Why would a user of > fink want to use the native python version, while fink provides a more > up-to-date version? I think you misread what I said above. Actually, please make sure you use the fink version of python when you do the test of the installed examples. The point is I am not sure you used the fink version last time when you could not import _plplotc into python so I would like to test that again (if you have time). The plplot-test.sh script invokes test_python.sh which in turn invokes the configured version of python, but the question is which version is that? Do grep -i python test/test_python.sh to see whether you are using the fink version or the native version. Even if it is the required fink version now, it is not clear that was true when you did your test before (it depends on how your PATH was set at the time of your test). Until this thread I never knew before you had two versions of python on your system, and if you have time I would appreciate you running the requested test knowing absolutely that you are using the fink version of python. If you can now build and install the python interface using the uncommented line in bindings/python/Makefile, and run the python example without problems (using fink python), then this means Mac OS X is no longer a special case, and I can substantially simplify our configuration scripts. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-03-20 22:52:13
|
On Mar 18, 2004, at 9:12 PM, Alan W. Irwin wrote: > The plplot-test.sh script invokes test_python.sh which in turn invokes > the > configured version of python, but the question is which version is > that? Do > > grep -i python test/test_python.sh that returns /sw/bin/python The python examples all run fine, using your modification that you suggested for the python Makefile. hth, - Koen. |
From: Alan W. I. <ir...@be...> - 2004-03-21 00:16:19
|
On 2004-03-20 17:52-0500 Koen van der Drift wrote: > > On Mar 18, 2004, at 9:12 PM, Alan W. Irwin wrote: > > > The plplot-test.sh script invokes test_python.sh which in turn invokes > > the > > configured version of python, but the question is which version is > > that? Do > > > > grep -i python test/test_python.sh > > that returns /sw/bin/python > > The python examples all run fine, using your modification that you > suggested for the python Makefile. Thanks for running this test. It appears the Mac OS X workaround for linking the python interface is no longer required so I have removed it from the cvs version. Please test python again when the next tarball comes out to make sure everything is fine. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |