I have a C++ dll file that uses a lot of other c++ librarys (IPP, Opencv +++) that I need to load into matlab. How can I do this?
I have tried loadlibrary and mex. The load library does not work.
The mex finds the linux things (platform independent library) and tries to include them. And that does not work.
Does anyone have any good ideas?
loadlibrary should work. I use it all the time to call functions from dlls written in C++ with C wrappers.
What errors are you getting when you try to use loadlibrary?
Make sure that the exported functions of the dll are C functions, not C++ functions. If not, then write C wrappers.
More info on exactly what you are doing when using loadlibrary would be helpful.
As mentioned by others, you should first wrap your C++ library as a C library - mathworks used to advise not to use C++ code directly in mex (dlopening C++ core directly is complicated), maybe it is still true.
Your description is quite unclear, too: what do you mean by "mex finds the linux thing", but that does not work. Saying that it does not work is not helpful: the exact commands and error message are.
You could go for the Java approach (since Matlab runs on a JRE and can access Java objects/methods -- just be aware that the Matlab JRE is not as up-to-date as the latest JRE, the one I'm running uses Java 1.5) and use JNA to access your DLL.
Or, if you wrote the top-level DLL, you could go for the COM/ActiveX approach.
I've had good success architecting the interface to my C++ functions as COM/ActiveX libraries -- you don't have to bother with that .h stuff.
See the External Interfaces guide on COM clients, particularly the part about managing/converting data.
It would be extra work to add the COM/ActiveX layer, but would make your library more portable within the Windows world and probably more easily used in MATLAB.
If you have a lot of function calls to your DLL, the COM/ActiveX approach might be faster (not sure), but otherwise I think the JNA approach would be easier.
Related
I have a C++ project that was used to create a DLL. Is it possible to take that C++ code and create a DYLIB file? I have only done a tiny bit of work with C++, so I am not sure if this can easily be done. Basically, I have an app that I rewrote in Python so I could run it on Windows or macOS. The Windows version of the app is able to use the DLL without a problem. Now, I would like to use the library with the macOS version of the app.
In general, of course, it is possible. However, whether it will be an easy job or not depends on whether how the library was written.
In the best case: you only need to recompile the library in macOS following its build instructions (e.g. typically explained in the documentation or in a README-style file in the root of the project).
In the worst case: the library is not portable at all (e.g. depends on the Windows API) and you won't be able to use it without rewriting it.
A side question is whether you really need the library: it is possible that you can find a Python library to fulfill the same job.
Recently I've been diving into Matlab and extending it with c++ code. So far I have had some success with the sample timestwo compiling it to a mex file via either the built-in mex commands as well as precompiled form with Visual Studio 2015. What I am really curious to discover is whether or not it's possible to actually bundle multiple s-functions into a single module.
Ideally I would like to have a single module that could contain between 10-20 routines of handwritten code, so this code could be used in a shared toolbox. What I haven't been able to find out though is how you force matlab to look for the function in a specific dll, it appears to always use the 'function name' as dll name. Are there any tips or examples about a multi-function setup?
You cannot bundle multiple s-functions into a single library. To share code you need to compile the shared functions as a separate library and then you can link the same library to each s-function. The shared library can be either static or dynamic depending on your design. You need to make sure all memory allocation for an instance of s-function is done by s-function possibly as DWorks and then pass the memory to shared functions for additional work.
I need some help with wrapping C++ libraries in XCode.
What I want to achieve is to create new library in XCode, import C++ library (I have .a and .h files), wrap it to Obj-C so I can import that library to MonoTouch.
The reason why I do it round way is that when I try to import C++ lib into MonoTouch, because of name mangling I keep getting WrongEntryPoint exceptions. Correct me if I'm wrong but there is no way for me to find out mangled names, which depends on compiler.
Thank you in advance
Correct me if I'm wrong but there is no way for me to find out mangled names, which depends on compiler.
Technically you could. Many compilers share the same mangling syntax, maybe the most useful and long-lasting gift from Itanium ;-)
However it will bring it's own pain (e.g. non-primitive types, other compilers) and maintenance issues as you update your C++ code.
You'll better served by:
writing an ObjectiveC wrapper and use MonoTouch's btouch tool to generated bindings;
writing a C wrapper and using .NET p/invoke to call your code;
The choice it yours but if you think about reusing the C++/C# code elsewhere (e.g. Mono for Android) then using C and p/invoke will be reusable.
I would definitely recommend going the route of wrapping the library in an Obj-C library and using btouch to import the library into MonoTouch. I have recently done this for a C++ library that implemented a Sybase database engine. If you look at my questions you will find quite a few pertaining to wrapping C++ libraries as I posted a few times regarding issues I encountered.
Specifically, you can look at these questions:
Linking to a C++ native library in MonoTouch
Wrapping a C++ library in Objective-C is not hiding the C++ symbols
Application with static library runs on simulator but not on actual device
Undefined symbols when linking PhoneGap static library in MonoTouch
Linker options 'Link all assemblies" and "Link SDK assemblies only" causes undefined symbols in 3rd party static library
I would also recommend, if you are going to go the route of an Obj-C wrapper, that you get btouch to output code and include that in your project rather than including a dll from btouch. From my experience, the code worked more reliably than the dll, although the issues with the dll may have been resolved by now. But take a look at this question regarding the btouch issue:
Exception System.InvalidCastException when calling a method bound with btouch that returns an object. MonoTouch bug?
If you have specific questions/problems in building the Obj-C wrapper then ask them here and post some code and I am sure that I or other members of the community would be able to help you with it.
Bruce, as you assumed, I have problems with wrapping C++ code. After hours and hours of reading and trying, I couldn't wrap the C++ code.
Anyway, I managed to create a simple Obj-C library made of some dummy class, and then import it into another library. That worked fine. However, following same pattern, I included C++ .a file along with .h file (I'm not sure whether .h is mandatory because we can link header files in build options, right??) and when I compiled it, it went fine, the build succeeded, but XCode didn't produce new .a library.
I added linker flags: -ObjC -lNameOfLib
Does C++ Standard Library Type in Build - Linking has to be Static? And Symbols Hidden By Default as well?
It would be great if we could write step-by-step tut, since there are tons of various instructions, but I haven't been able to push it through the end.
I'm confused a bit..
Thank you guys...
I've encountered a strange behavior in __declspec(dllexport) in my project.
I have a C++ project that uses classes, namespaces, try-catches and more cpp elements.
When exporting any dummy function in this DLL, no other C project will be able to load it with LoadLibrary (Getting error 'module not found').
Is it possible to load dynamically C++ dlls through C projects?
These projects are Windows Mobile projects, but they should behave the same as on regular PC win32.
I'm stuck on it and any help will be appreciated.
Thank you,
Emil.
LoadLibrary is completely oblivious to the language used to compile a module. If LoadLibrary says it can't find the module, then it's very likely the case that it really can't find it. Make sure you've specified the right file name. If you've included a drive and path, make sure they're correct, too. If you haven't included a drive or path, then make sure the file exists somewhere where LoadLibrary can find it. The places it searches are listed in Dynamic-Link Library Search Order. Also consider whether Windows Vista's directory-virtualization feature might be interfering.
Once the DLL is loaded, you may have any number of other issues in using the C++ DLL from your C code. The C++ compiler may have mangled the function names, so you'll need to provide the right names when you call GetProcAddress. The C++ code might use a different calling convention from what your C code expects, so you may need to change declarations in the C++ code, the C code, or both. If the C++ functions expect to receive pointers to classes or other C++-specific types, you'll need to change your C++ code so that its API is compatible with C. If your DLL allocates memory that the host program should free, or vice versa, you'll need to make sure that both modules can use the same memory manager.
All that is separate from the problem you're reporting, though, which is simply that the OS can't find your file. Focus on that first.
I found the problem. It was really a dependency dll problem. It was not found in the directory of the loading DLL.
Thank you all.
I'll preface this by saying I'm a C# programmer who inherited horrible code with no documentation. I have an unmanaged C++ library wrapped with managed code that worked fine in VS2003 with .Net 1.1 Framework. I'm trying to get it upgraded to at least .Net 2.0.
I have the unmanaged C++ library that was compiled with "MSVC 8.x" (thus equivalent to VS 2005, I assume). I've been trying to migrate everything to VS2008 and still have some issues with this library at runtime.
My question is this: should this library work with VS2008? Or should I be developing in VS2005 if the library was compiled with VC8.x?
Any thoughts would be greatly appreciated. Thanks!
It should work, I expect that you are having issues with your marshalling. It is probably stuff that was declared incorrectly for PInvoking that managed to work in .NET 1.1 but not in later versions.
You don't say what sort of problems you are having at run time, nor do you state how you access your library. For example, do you compile your library along with your project? If so, can you turn on unmanaged debugging in your C# project and step into the code you are having trouble with? How are you calling the unmanaged code? Is it through PInvoke, or do you have managed C++ wrappers?
In my experience, the best solution for calling out to a legacy unmanaged library is to add a managed wrapper library for your legacy library written in managed C++. This way you present a managed interface for your library for all .NET languages to consume and you don't have to worry about getting your PInvoke signatures correct.
Your project should look something like this.
C# Application -> Manage C++ Wrapper DLL -> Legacy DLL
It can depend what else the lib relies on. For example, if you are using the STL across the library interfaces then it would be a bad idea to have the library compiled with a different version to the client. However, if the library presents a simple C style function interface then you shouldn't have problems.
If you have the source code for the library then I would recommend trying to port it to VS2008. In general it is much less hassle in the long run to have everything in the same development environment.
How are you wrapping the unmanaged lib ... presumably using managed extensions for C++ if it dates back to VS2003. This is now deprecated and has been replaced with C++/CLI as of VS2005. Whilst the newer compilers support a /clr:oldSyntax switch to still compile the old code there are definitely issues with it. We have old code that will not compile on VS2005(8) using this switch.
--Rob Prouse:
The wrapper uses managed C++, no PInvoke. The wrapper is compiled into a DLL that is then used by another application (as you illustrated).
The legacy code produces graphics objects. When I try to get the handle to an image, I get a null exception instead. The debugger doesn't let me get farther into the code to figure out why. Everything else seems to run ok - the other data objects needed to create the image exist and appear to be correct. (Sorry, I know that is still a pretty vague description.)
--Rob Walker:
I unfortunately do not have the source code.
Not sure about "using the STL across the library interfaces". Does graphics fall under that category?
I was able to get my application to run with using the /clr:oldSyntax switch, but that's where I get the null handles to images. I tried to put in all the modifications so that it would compile with /clr, but then I kept getting link errors that I couldn't resolve. (The linker kept complaining about not being able to find files even though those files were in the folder where it was looking.)