-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A cross-platform AnyCPU approach #40
Comments
New version of the library: https://github.com/AndreyAkinshin/InteropDotNet |
I am sorry for the late reply. Your new solution is so great. Thank you. I have a question. To use your solution, I understand that release package should be bundled with Win32 library (.dll) and Unix library (.so). I think a .so file that built in Linux probably does not work in BSD. So I have to bundle a package with many library files for all platforms. This is not realistic. Is this understanding mistaken? In general, Unix platforms have some powerful package managers (e.g. apt, yum, homebrew, ...). For example, the command |
This is not a problem. I can implement any logic for library name resolving. Please, look to the LoadLibrary method of the LibraryLoader class. That's all we need. So, I can implement new logic myself if you tell me what you want for each platform. |
I understand the name resolving logic. It is cool. My fear is that I need to prepare many many OpenCV library files for all platforms on every OpenCV version upgrade. This is a different problem from your system. By the way, the Mono's DllMap system seems to have name resolving system that is similar to your project. <configuration>
<dllmap dll="libc">
<dllentry dll="libdifferent.so" name="somefunction" target="differentfunction" />
<dllentry os="solaris,freebsd" dll="libanother.so" name="somefunction" target="differentfunction" />
</dllmap>
</configuration> |
Ok, I get it. I think that it is not a problem to use installed opencv library from specific os system folder.
I met a problem with native dependences between libraries when I tried apply the DllMap aproach for Tesseract wrapper. If you can use DllMap for OpenCvSharp, it will be so great. In this case you can use DllMap for Mono and WindowsLibraryLoader for MS .NET Runtime. But if you also meet some problems, I am ready to update my InteropDotNet library for you needs. |
Any updates? What is the expected time for Linux support? |
Any updates? |
I am very sorry for the late reply 🙇 I am sorry but I think it has little significance because Mono's DllMap works fine on my environment (Debian wheezy & MacOSX). DllMap config files are already attached to the OpenCvSharp release packages. |
Ok, I will try it. But now I have some troubles with OpenCvSharpExtern building under Debian. There is an error:
What should I do? Can you provide ready binaries of the OpenCvSharpExtern library for popular Linux distributives (like Debian)? |
Debian wheezy — the same problems. My steps:
to opencvsharp directory.
from the opencvsharp/src directory.
What am I doing wrong? |
I'm having the same issue building on OS X 10.9 - I'd love to know what I'm doing wrong as I've been banging my head against this wall for quite a while now! |
Thank you. The CMake configuration was fixed: 83caebd |
Please forgive me and correct me if I'm wrong. This cross-platform approach means my application would have all opencv .so (or .dll, for Windows) files in the bin folder, so the user wouldn't need to install opencv on his machine? Assuming the size of my application is not an issue, did I get it right? Is there a way to do it with OpenCvSharp? Thanks in advance! :) |
I fixed Cmake config problems of OpenCvSharpExtern. (please discuss this issue in #10) win39> I guess you are right. but I do not know much about shared library in unix. |
Hi, in #26 we discussed a problem of AnyCPU support for Windows and Unix. Unfortunately, I could not find a beautiful solution based on the
DllImport
attribute because of Mono and Microsoft .NET Runtime have different algorithms that work with native libraries. So, I developed own approach: we can generate calls of native method on the fly by signatures from some interface. Please take, a look at my solution: https://github.com/AndreyAkinshin/DotNetRuntimeImplementerIf you like this approach, I can modify it to your needs.
The text was updated successfully, but these errors were encountered: