On Sep 3, 2008, at 1:01 PM, Darren Weber wrote:
Thanks heaps for some very useful insight into resolving my OSX
nightmares.
It always helps to RTFM! I was starting to think there is a problem
within the .so file and how it specifies the location of the dylib
required (path and version). As yet, I have no idea how to "debug"
that. I was stratching around for ldd or something and actually
started to read a couple of man pages on dlopen, but I didn't get far
enough with that and started to hack symlinks (no so elegant). So, I
guess most of the dlopen paths point to framework locations (NeXT
stuff), rather than a full search of /usr/local/lib/, but I do have to
RTFM on that, among many other OSX things ;-)
I think OS X looks in /usr/lib as one of its default paths. /usr/local/
lib is NOT searched by default. Frameworks are a whole new beast. Not
everything on OS X has to be a framework. Apple would like you to use
them but lots of people get along with a standard unix style layout of
bin, include, lib, share. You can build a framework if you want or you
can use the standard unix layout. If you choose to just use a unix
layout it is my suggestion to install it to /usr/local/MyProject/ or
something like that although a common user would never know about this
location. You can also use /Users/Shared/MyProject for that matter
which is easier to find using the "Finder"
Another option may be to hard code the paths in the .so build
(somehow), so that's another avenue to learn about (the build learning
curve is moderated by ccmake, but not entirely when you need to tweak
a few things). I could not find instances of these variables in the
main ccmake interface:
<snip>....
Darren
On Wed, Sep 3, 2008 at 1:02 AM, Martin Costabel
<[EMAIL PROTECTED]> wrote:
Darren Weber wrote:
[]
ImportError: dlopen(/usr/local/lib/python2.5/site-packages/vtk/
libvtkCommonPython.so, 10): Library not loaded:
libvtkCommonPythonD.5.2.dylib
Referenced from: /usr/local/lib/python2.5/site-packages/vtk/
libvtkCommonPython.so
Reason: image not found
This is not a problem you can solve with PYTHONPATH. It is not
python that is trying to find the dylib, but dlopen(). And dlopen
does not look at PYTHONPATH.
There are several different ways how you can solve this problem (as
always on Mac OSX, given its hybrid Unix/NextStep nature):
The simplest and cleanest way (this is how it is done by the Fink
VTK package, for example, perhaps also by macports vtk5) is to
build vtk in such a way that its dylibs have decent install_names
that correspond to the place where they are installed. In this way,
dlopen() finds the dylib without any help, because the full path
name (or a correct relative path name) of the dylib is hardcoded
inside the libvtkCommonPython.so python module. For example, I get
from the command
otool -L /sw/lib/python2.5/site-packages/vtk/libvtkCommonPython.so |
head -n3
the output:
/sw/lib/python2.5/site-packages/vtk/libvtkCommonPython.so:
/sw/lib/vtk/libvtkCommonPythonD.5.0.dylib (compatibility
version 5.0.0, current version 5.0.4)
/sw/lib/vtk/libvtkCommon.5.0.dylib (compatibility version
5.0.0, current version 5.0.4)
You see the whole path of libvtkCommonPythonD.5.0.dylib there. I am
sure in your case, you will see only "libvtkCommonPythonD.
5.0.dylib", without its path. This is the default when building
VTK. If you want to get the correct install_name, you have to build
VTK (this is for 5.0, I haven't tried 5.2 yet) with the cmake
parameters
-DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
-DVTK_USE_RPATH=ON
Another way to help dlopen, if your VTK is built without
install_names for its dylibs, is to use one of the environment
variables LD_LIBRARY_PATH, DYLD_FALLBACK_LIBRARY_PATH or
DYLD_LIBRARY_PATH (do *not* use the latter, it risks wreaking havoc
on your system). See "man dlopen".
--
Martin
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
_________________________________________________
| Mike Jackson - Principal Software Engineer |
| BlueQuartz Software |
| [EMAIL PROTECTED] |
| www.bluequartz.net |
---------------------------------------------------
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
