Linking Problem

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download pyopencv and change to source directory
2. run "mkdir build && cd build && cmake .."
3. build and install pyopencv

What is the expected output? What do you see instead?

boost library is not found (I attached a fix for this).  Once that is fixed 
when I import pyopencv I get the following error:

>>> import pyopencv
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyopencv/__init__.py", line 1, in <module>
    from info import __doc__
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyopencv/info.py", line 42, in <module>
    import config as _cfg
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyopencv/config.py", line 7, in <module>
    from cxtypes_h import *
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyopencv/cxtypes_h.py", line 19, in <module>
    import cxtypes_h_ext as _ext
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyopencv/cxtypes_h_ext.py", line 17, in <module>
    __bootstrap__()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyopencv/cxtypes_h_ext.py", line 13, in __bootstrap__
    imp.load_dynamic(__name__,__file__)
ImportError: 
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
/site-packages/pyopencv/dl-cxtypes_h_ext.so, 2): Library not loaded: 
build/lib.macosx-10.6-x86_64-2.6/pyopencv/libpyopencv_extras.dylib
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyopencv/dl-cxtypes_h_ext.so
  Reason: image not found

What version of the product are you using? On what operating system?

I am using the svn version on mac os x.

Please provide any additional information below.

The first issue is fixed by the small patch to CMakeLists.txt (attached) - it's 
a problem with the lib prefix not being dropped from library names in the 
revise_libs function.

The second issue appears to be a linking one: during the build process, 
pyopencv links to the absolute location of libpyopencv_extras.dylib (and I 
think others as well) instead of the relative one.  Thus, once the package is 
installed the linkages are broken.

Original issue reported on code.google.com by aber...@gmail.com on 17 Aug 2010 at 9:28

Attachments:

• patch-CMakeLists.txt.diff

[GoogleCodeExporter]

Thanks a lot. I'll try to include that patch to the CMakeLists.txt file. It's 
not working with Ubuntu though. As for the linking problem. Make sure you have 
run:

ldconfig

after installing if you are on Ubuntu. I haven't figured out how to register a 
shared library on Mac OS X though.

Cheers,
Minh-Tri

Original comment by pmtri80@gmail.com on 18 Aug 2010 at 6:28

[GoogleCodeExporter]

Original comment by pmtri80@gmail.com on 18 Aug 2010 at 6:28

• Changed state: Accepted

[GoogleCodeExporter]

So I figured out the issues with the linking to some extent:

the first (for which I attached the patch) whereby the lib prefix needs to be 
removed is that -l<name> under mac os x (and I thought under linux too, but 
maybe not) prepends a 'lib' to the name and appends a .so to it.

the second issue right now I fixed by using the 'install_name_tool' command.  
Specifically I ran:

install_name_tool -change 
build/lib.macosx-10.6-x86_64-2.6/pyopencv/libpyopencv_extras.dylib 
libpyopencv_extras.dylib dl-cv_h_ext.so

(then repeated it to the other so's).  I will post a better fix for 
CMakeLists.txt, but I haven't gotten this working yet.  I think that the fix 
will involve passing a -install_name argument to the linker at compile time 
(this is more or less equivalent to the linux rpath).

Now I can run certain examples, but other's seem to crash pretty badly 
(corrupting the stack) so I think that there are still 32-bit vs. 64-bit issues 
remaining in the code.  I'll post another issue for this.

Original comment by aber...@gmail.com on 20 Aug 2010 at 6:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Awesome. Thanks for the update.

On Windows, I noticed that shared libraries compiled by setuptools (i.e. by 
running "python setup.py install") crash occasionally, whereas the same 
libraries compiled by cmake (i.e. by running "make") do not have any problem. 
Thus, if you are using setuptools, I'd like to recommend you to try to compile 
and install using cmake instead, e.g.

mkdir build
cd build
cmake ..
make
make install

The linking problem may not be present in cmake but there might be no more 
crash.

Cheers,
Minh-Tri

Original comment by pmtri80@gmail.com on 20 Aug 2010 at 6:52

[GoogleCodeExporter]

Unfortunately, the same linking problems exist when I use cmake to compile and 
build pyopencv.  In fact, using cmake actually exacerbates the problems on a 
mac, since often people have multiple python distributions installed and cmake 
picks up the system one by default and it takes a fair amount of hacking to get 
it to pick the right one.  Setuptools on the other hand picks whichever one is 
currently running the script.

The problem stems from libpyopencv_extras being a shared library and its 
location is picked up and hard coded into the various components of pyopencv 
(e.g. dl-cxtypes_h_ext.so)  at compile time, but it moves.  I"ll post a fix for 
this as soon as I will, but for now the install_name_tool hack works for this.

Original comment by aber...@gmail.com on 23 Aug 2010 at 6:48

[GoogleCodeExporter]

With the attached patch pyopencv compiles on a mac.

By the way:  I tried compilation under 64-bit ubuntu and this patch seems 
necessary to make it work with setuptools there as well. 

Original comment by aber...@gmail.com on 24 Aug 2010 at 4:21

Attachments:

• patch-CMakeLists.txt.diff

[GoogleCodeExporter]

Great! Thank you very much for the patch. I will update CMakeLists.txt shortly.

Do you think if there is any chance that the "-install_name" link flag also 
works on Ubuntu? Right now, I don't know how to avoid running "ldconfig" after 
installing pyopencv, either via setuptools or cmake. But OpenCV can avoid doing 
it so there must be a way.

Cheers,
Minh-Tri

Original comment by pmtri80@gmail.com on 24 Aug 2010 at 5:20

[GoogleCodeExporter]

I think the Linux the equivalent of insyall_name is "rpath" which stands for 
runtime path.   I haven't played around with it yet though - if I have time 
I'll check it out to see if I can get it working under Linux too. 

Original comment by aber...@gmail.com on 24 Aug 2010 at 5:26

[GoogleCodeExporter]

The latest svn version now compiles on a mac with setuptools as per the 
instructions.

Original comment by aber...@gmail.com on 25 Aug 2010 at 4:02

[GoogleCodeExporter]

I'd like to close the issue. I've managed to fix the 'ldconfig' issue by adding 
INSTALL_RPATH to CMakeLists.txt. There's no need to run 'ldconfig' on Ubuntu 
anymore. Thanks for your help.

Cheers,
Minh-Tri

Original comment by pmtri80@gmail.com on 27 Aug 2010 at 7:45

• Changed state: Fixed