Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Can you try adding the following to the additional mtouch arguments in the project's iOS Build options:
and enable the linker (either SDK or all assemblies). This will bind the P/Invokes at build time instead of at runtime and should at least work around the issue.
I'll continue investigating why this is happening in the first place.
We have tried to check this issue with the attached project Url but We don't have permission to the repo project.
Could you please provide us the repo project to reproduce this issue ?
Anyone with the link can now download it.
(In reply to comment #2)
> We have tried to check this issue with the attached project Url but We don't
> have permission to the repo project.
> Could you please provide us the repo project to reproduce this issue ?
(In reply to comment #1)
> Can you try adding the following to the additional mtouch arguments in the
> project's iOS Build options:
> and enable the linker (either SDK or all assemblies). This will bind the
> P/Invokes at build time instead of at runtime and should at least work around
> the issue.
After adding the argument and re-enabling the linker, the P/Invoke now works. Interestingly, the method implementation throws an exception and now logs the following error message to the console:
OpenCV Error: Bad argument (Unknown array type) in cvarrToMat, file /Users/zgramana/opencv-188.8.131.52/modules/core/src/matrix.cpp, line 698
libc++abi.dylib: terminating with uncaught exception of type cv::Exception: /Users/zgramana/opencv-184.108.40.206/modules/core/src/matrix.cpp:698: error: (-5) Unknown array type in function cvarrToMat
But this gives me something to troubleshoot now.
The problem is that the symbols end up as private symbols in the executable, so when mono tries to look them up, they're not found (note the lowercased 't' in nm's output - this indicates the symbol is private. If if were public, it would be an uppercased T).
I haven't found out exactly why this is so, but it's how the third-party native library was built (either compiler flags, or function attributes in the source code).
The library's cmake file was set to build with -fvisibility=hidden, which apparently is the default in Xcode when C++ is enabled. Rebuilding with -fvisibility=default made the symbol public again.
There still seems to be some kind of memory formatting error, though. Just passing the pointer to the cv::Mat object through from the ProcessImage callback to the underlying C functions results in opencv not recognizing the object type once deferenced.
Closing this bug report then, since the reported issue (EntryPointNotFoundException) has been resolved.
Please open a new bug report if you have any other bugs.