Bug 18840 - P/Invoke always fails with EntryPointNotFoundException
Summary: P/Invoke always fails with EntryPointNotFoundException
Status: RESOLVED INVALID
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 7.0.0.x
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-04-07 12:11 UTC by Zack Gramana
Modified: 2014-04-09 09:18 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED INVALID

Comment 1 Rolf Bjarne Kvinge [MSFT] 2014-04-07 13:11:40 UTC
Can you try adding the following to the additional mtouch arguments in the project's iOS Build options:

    --dlsym:false

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.
Comment 2 Ram Chandra 2014-04-07 14:05:45 UTC
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 ?
Comment 3 Zack Gramana 2014-04-07 14:29:35 UTC
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 ?
Comment 4 Zack Gramana 2014-04-07 14:36:16 UTC
(In reply to comment #1)
> Can you try adding the following to the additional mtouch arguments in the
> project's iOS Build options:
> 
>     --dlsym:false
> 
> 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.

Progress!

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-2.4.8.2/modules/core/src/matrix.cpp, line 698
libc++abi.dylib: terminating with uncaught exception of type cv::Exception: /Users/zgramana/opencv-2.4.8.2/modules/core/src/matrix.cpp:698: error: (-5) Unknown array type in function cvarrToMat

But this gives me something to troubleshoot now.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2014-04-08 10:14:05 UTC
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).
Comment 6 Zack Gramana 2014-04-08 13:01:31 UTC
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.
Comment 7 Rolf Bjarne Kvinge [MSFT] 2014-04-09 09:18:32 UTC
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.