Alan W. Irwin writes: > On 2009-07-01 00:09-0500 Geoffrey Furnish wrote: > > HOWEVER: PLplot's Python binding needs numpy. And here comes the rub. > > It turns out that Numpy's installation will *not work* if the python was > > built --enable-shared. If you don't build --enable-shared, then you can > > go into the numpy distribution and run $PREFIX/bin/python setup.py > > install, and it goes right where you want it, under $PREFIX. But if > > your installed $PREFIX/bin/python was configured with --enable-shared, > > then KABOOM, when you run numpy's installer, it tries to write into > > /usr/lib64/*, and ignores the PREFIX to which your python was > > configured. > > One possibility is that the automake based build you seem to be using for > python may be outdated. Surely, you can now build a new version of python > using an old version of python and the setup.py approach? It's possible > if you do that, then numpy will work fine.
Mmm, I'm not really understanding this suggestion. But I did spend some time today trying several ideas for ways to get the .so into an otherwise non-so version of python configured to a particular prefix. I could not find any way to get all three of these things at the same time: --enable-shared, custom prefix, and numpy on board. > Another possibility is that in the _numpy_ setup.py, there was a simple > oversight where they hardcoded the system path rather than taking into > account the possibility that you are building and installing all > python-related items with your own PREFIX. The setup.py seems deceptively simple, but all the complexity lies buried deep within things that are called from there. Numpy likes to link against all kinds of stuff, and has a very thorough search system to finds all kinds of mathematical software you might have on your system. I have to shut all this off, and make it do exactly what I want, for all the same reasons as I described in the former e-mail, motivating the whole concept of the application specific prefix. Maybe numpy's installer works better in other configurations, but not in mine. > It's been years since I have debugged a setup.py file, but IIRC they are > usually pretty short so it may not be that difficult for you to debug this > issue. But if you cannot do that, then a numpy bug report is certainly > indicated. Yeah, it does seem I should do that. > > [...]The only solution to this unholy mess that I have been able to > > find, is to leave PYTHON_LIBRARIES off the link line for the PLplot > > python extension modules. On Linux at least, I know that this omission > > is inconsequential. When you actually load the extension modules at run > > time, the symbols are filled in from the dynloading executor process > > (which in my case will turn out to be an embellished python with some > > application-specific python extension stuff compiled in). And all is > > well. > > This seems like a reasonable temporary workaround for the bug in numpy > installation, but the problem is we have already historically gone through > platform testing of excluding PYTHON_LIBRARIES, and it caused problems. > Thus, removing PYTHON_LIBRARIES now will always introduce a question mark > about the reliability of our python extension module builds. (That > concern would be reduced by redoing the platform testing again, but even > if it worked now for the platforms we are able to test, it still leaves a > question mark for the platforms we are not able to test at this time.) > > To avoid that question mark, I suggest the following compromise. > > Put in a cmake option (EXCLUDE_PYTHON_LIBRARIES) which you can set for > your needs, and which everyone else can ignore. We can then remove that > workaround once the fundamental issue with numpy is fixed. > > Once I have the okay from you for this approach, I can implement it in about > 5 minutes inside cmake/modules/python.cmake by setting PYTHON_LIBRARIES to > nothing if EXCLUDE_PYTHON_LIBRARIES is true. Okay, I didn't perceive the extent of prior work in this area. I'm good with your suggestion. And thanks much for offering to whip that up in cmake. I'm sure you can do it a lot faster than me at this point in time. -- Geoff ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
