Closed GoogleCodeExporter closed 8 years ago
This error:
AttributeError: dlsym(0x324b50, cvCreateFeatureTree): symbol not found
means that function cvCreateFeatureTree() is not found in the detected
'libcv.dylib'
file. Can you check for me if the function cvCreateFeatureTree() was compiled
and is
working well in your the OpenCV installation?
Original comment by pmtri80@gmail.com
on 30 Jan 2009 at 7:52
I'm on the latest stable revision tag of openCV
Revision 1569.
No showstopping errors through cmake, make, or make install.
libcv.dylib is definitely installed.
How can I test if libcv.dylib is working well?
Original comment by candersonmiller
on 30 Jan 2009 at 8:06
I don't have a problem on an OS X 10.4/Tiger system with r1454 from late
December,
but can try bumping up to the latest trunk revision when I get a chance later
this
evening.
You might try running "nm libcv.dylib | grep _cvCreateFeatureTree" on your
system and
seeing if the symbol is present.
I'd probably also try printing opencv._cvDLL just to verify that it's loading
the
copy of libcv.dylib that you expect.
Original comment by db3l....@gmail.com
on 31 Jan 2009 at 1:02
"nm /usr/local/lib/libcv.dylib | grep _cvCreateFeatureTree" returns no results
- in what environment would I print opencv._cvDLL?
Original comment by candersonmiller
on 31 Jan 2009 at 1:32
From comment 4, it looks like the cvCreateFeatureTree symbol does not exist
from your
current libcv.dylib file. One way to test if this function is available in your
installation is to execute a simple piece of C code below and see if there is
any
compilation error.
#include "cv.h"
int main(void)
{
CvMat* mat = cvCreateMat(10, 20, CV_64FC1);
CvFeatureTree *tree = cvCreateFeatureTree(mat);
return 0;
}
Original comment by pmtri80@gmail.com
on 31 Jan 2009 at 3:26
test.c:6: error: ‘CvFeatureTree’ undeclared (first use in this function)
So - it doesn't - what do I do now?
Original comment by candersonmiller
on 31 Jan 2009 at 4:21
I've found out that since r1475, function cvCreateFeatureTree has been renamed
to
cvCreateKDTree. It looks like there's been some development in the OpenCV's main
trunk now. Perhaps you might want to wait for them to stabilize their code
first.
Best regards,
Minh-Tri
Original comment by pmtri80@gmail.com
on 31 Jan 2009 at 6:04
okay - I just checked out and installed r1475 of the opencv library - and I'm
getting all the same errors. What
should I do if I want to get up and running soon?
Original comment by candersonmiller
on 31 Jan 2009 at 6:37
If you don't mind, can you try r1474 instead? r1475 is where the change was
made.
Unfortunately, I do not have a Mac OS to test so at best I can only speculate.
Best regards,
Minh-Tri
Original comment by pmtri80@gmail.com
on 31 Jan 2009 at 9:10
I just finished building against the latest trunk revision (1569) on my 10.4
system
(took a bit longer than I expected since apparently the configure approach
doesn't
handle building the local lapack library, so I needed to set up cmake).
It looks like this is the only incompatibility with the wrapper - at least that
I can
detect so far. So canderson, unless you need the function you can basically
just
comment out the code that tries to wrap it in your copy of the ctypes-opencv
package
if you want to avoid the error. Or you can locally apply the attached patch.
I'm attaching a proposed patch that wraps either function, calling it by the
later
cvCreateKDTree name. I've left an alias in for the older cvCreateFeatureTree,
but it
might be something not worth including, since anyone developing against 1.1 is
already going against a moving target anyway, so maybe better to just track the
trunk.
The patch also corrects CvFeatureTree to only release when appropriate, and to
have
_fields_ so repr() works. And lastly, I noticed that cvReleaseFeatureTree was
actually wrapping the old cvCreateFeatureTree, so adjusted that.
I don't actually know what sort of matrix contents the function wants, but with
the
patch the wrapper works with the trunk OpenCV on OSX, as well as 1.0 and
1.1pre1 on
Windows, inasmuch as I can call it with a random 32x32 vector.
-- David
PS: There are some other _Structure subclasses that also don't define _fields_,
and a
handful with _fields_ of [] so I'm thinking that perhaps _Structure should have
an
empty _fields_ = [] definition to at least keep the other structures repr()able
and/or avoid their need to define an empty list if they have no accessible
fields?
Original comment by db3l....@gmail.com
on 31 Jan 2009 at 9:49
Attachments:
Thanks David for your great effort in making ctypes-opencv compatible with
r1569. I
have taken your advice and added "_field_ = []" to _Structure. However, I'd
rather
just support the official releases of OpenCV. I do not have time to follow every
OpenCV's trunk revision, not to mention that we need to identify which revision
is
stable enough for supporting.
Canderson, please let us know if your problem is still not resolved. Otherwise,
I'd
like to close this issue.
Minh-Tri
Original comment by pmtri80@gmail.com
on 2 Feb 2009 at 1:31
First, no problem with this from me - at worst this is a patch that can be
applied
locally by someone using the trunk until the wrapper is officially updated.
I am curious though - do you consider 1.1pre1 a full release? I saw it just as
an
early snapshot/pre-release/release candidate for what will eventually be 1.1, so
while it's interesting in terms of having some binaries at that specific
revision,
and worth testing against as a discrete release, it seems to me that someone
using
1.1 at the moment is just as likely to be tracking the trunk as it evolves since
1.1pre1 went out with some known issues.
I'm certainly not advocating daily tests against the trunk, but if we happen to
get
lucky and someone catches something that we can cover before it gets formalized
as
1.1pre2 or 1.1, so support could already be in the wrapper, all the better. I
suppose there's some risk the change will be reverted, but the wrappers are
still in
development too.
Oh, independent of the above you may want to cherry pick the portion of the
patch
that corrects the wrapper for _cvReleaseFeatureTree, since right now it calls
cvCreateFeatureTree. The addition of _owner to CvFeatureTree may be useful too
(though less of a strong argument) since if you happen to create that structure
directly at some point, you'll crash when you exit Python and it tries to
release itself.
Original comment by db3l.em...@gmail.com
on 2 Feb 2009 at 4:00
Oh. Sorry I have missed out your reply. I have some points to discuss with but
at the
moment I don't have time for ctypes_opencv. I have some matters in real life to
take
care of. I'll answer you asap, but probably not until March 10. I apologize.
Best regards,
Minh-Tri
Original comment by pmtri80@gmail.com
on 24 Feb 2009 at 6:48
I just finished my oral defence last Friday. Let's continue our discussion. I
understand there are some known issues with 1.1pre1. Also, I'm aware that there
are
some significant changes in OpenCV's interface, which may break our
ctypes-opencv in
the future. I'm ok with supporting the trunk. We need to nail down which
revision to
support. Is there any way to detect which revision the user is using? Otherwise,
perhaps we can create a branch to support the trunk.
Meanwhile, I'll incorporate all the recent patches and release a bug fix
version.
Best regards,
Minh-Tri
Original comment by pmtri80@gmail.com
on 5 Apr 2009 at 6:41
In light of recent OpenCV development, I guess it is safe to wait until they
release
their new version, hopefully in this June, before we start wrapping new
functions.
Original comment by pmtri80@gmail.com
on 17 Jun 2009 at 3:09
Original issue reported on code.google.com by
candersonmiller
on 30 Jan 2009 at 6:12