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
