I'm fairly new to OpenCV and Visual Studio as well. My question is not so much technical but theoretically anyways:
I'm working on a bigger project but do not have access to all its subcomponents etc. I wrote a few classes and functions that other members want to use. However, I'm using some OpenCV specific things (because I'm lazy and dont want to implement everything all by myself) but the other members dont use it and they want to keep the project size relatively small.
My question is: How can I provide my code as a library or something similar that includes all my opencv dependencies? Can I create a dll of my code and just ship the opencv dlls with it? Is there a way to bundle everything into one file with only one header?
How would you solve this problem?
Summarizing: I want my functions in a library and shipped as small as possible (with opencv dependencies)
KR
Put all your code in a DLL, and then ship OpenCV DLLs along with yours.
Or: put all your code in a DLL, and perform static linking with OpenCV.
Related
newbie here.
Want to ask for any advice on how to Publish/Export, CodeBlocks Application made by using wxWidgets. After some research, i discovered that i should use DLL, or something like that, but since I am really new into it, I am missing the logic on how I should actually implement that. Since CodeBlocks offers wxWidgets and DLL as separate projects. So I am not really sure how to properly combine. Thanks in advance.
If you used wxWidgets as .dll, to get a self-standing package you have to distribute all the requested libraries. The simplest way is just to copy them from their source folder (in your case [wxWidgets root]\lib\gcc_dll) in the same folder as your executable. There could be many of them, but usually only two or three are needed. For simplicity you can copy them all, or you can try repeatedly to start the program, and add each time the library indicated in the error message.
Please note that to distribute your application you will probably want to compile it in Release mode, and consequently you should ship the Release .dlls (i.e. beginning with wx...28_ instead of wx...28d_).
I'm still not 100% sure with the framework linking process, but from what I've seen here before nobody has asked a similar question, perhaps because this could be a silly question, but I'll give it a go anyway.
In my current X-Code project, I'm using a custom framework, say example.framework. At the moment, as far as I'm aware of, in order for the program to function with the framework, I need to have it either in /Library/Frameworks, or I need to have it copied into the bundle resources in the build phase.
Would anybody know about adding a framework to a project in a way that it gets compiled into the executable, so I don't have to include the raw framework with the app? I'd rather not share the whole framework...
Thank you in advance! Any suggestions are also welcome!
A Mac OS X framework is basically a shared library, meaning it's a separate binary.
Basically, when your main executable is launched, the OS will load the framework/dylib into memory, and map the symbols, so your main executable can access them.
Note that a framework/dylib (bundled into the application or not), does not need to contain the header files, as those are only needed at compilation time.
With Xcode, you can actually decide whether or not to include the header files, when you are copying the framework to its installation directory (see your build phases).
If you don't copy header files, people won't be able to use your framework/dylib (unless they reverse-engineer it, of course).
If you still think a framework is not suitable for your needs, you may want to create a static library instead.
A static library is a separate object file (usually .a) that is «included» with your final binary, at link time.
This way, you only have a single binary file, containing the code from the library and from your project.
I'm building a project which consists of two .net executables, and a class library with common components that the two executables share. For ease of distribution, I was hoping to be able to distribute the two executables without distributing the dll (grab & run distribution).
Is there any way to have visual studio compile the contents of the dll into each executable without manually copying the classes into each project (and thereby replicating the code in more than one place)?
Don't make it a DLL. Make it a static library instead.
Digging around on SO I found a duplicate question which stated the problem quite a bit more clearly than I did.
ILMerge seems to be the solution.
Static Linking of libraries created on C# .NET
I have an application with a plug-in architecture that is using Boost.Threads as a DLL (specifically, a Mac OS X framework). I am trying to write a plug-in that uses Boost.Threads as well, and would like to link in the library statically. Everything builds fine but the application quickly crashes in my plug-in, deep within the Boost.Threads code. Linking to the DLL version of Boost.Threads seems to resolve the problem, but I'd like my plug-in to be self-contained.
Is it possible to have two instances of Boost.Threads with such a setup (one as a DLL, one statically linked in another DLL)? If so, what might I be missing to make the two instances get along?
Once my team faced a similar problem. For reasons I will not mention at this time, we had to develop a system that used 2 different versions of Boost (threads, system, filesystem).
The idea we came up with and executed was to grab the source code of both versions of Boost we needed, and then tweak one of them to change the symbols and function names to avoid name clashing.
In other words, we replaced all references to the name boost for bubbles inside the sources (or some other name) and also made changes to the compilation so it would build libbubbles instead of libboost.
This procedure gave us 2 sets of libraries, each with having their own binaries and header files.
If you looked at the source code of our application you would see something like:
#include <bubbles/thread.hpp>
#include <boost/thread.hpp>
bubbles::thread* thread_1;
boost::thread* thread_2;
I imagine some of the guys here already faced a similar situation. There are probably better alternatives to the one I suggested above.
I have an existing project created using C/C++ under a development environment.
Currently we want to facelift the existing form using a Window Forms application but the problem is the existing project is using Common Runtime Library = No /CLR and Runtime Library = /MTd.
But the a Windows Forms application is using Common Runtime Library = /CLR and Runtime Library = /MDd.
Please advise if it possible to use a Windows Forms application to create a form in the existing project?
Is there any tutorial regarding this?
The comment from MSDN was:-
Caution Do not mix static and
dynamic versions of the run-time
libraries. Having more than one copy
of the run-time libraries in a process
can cause problems, because static
data in one copy is not shared with
the other copy. The linker prevents
you from linking with both static and
dynamic versions within one .exe file,
but you can still end up with two (or
more) copies of the run-time
libraries. For example, a dynamic-link
library linked with the static
(non-DLL) versions of the run-time
libraries can cause problems when used
with an .exe file that was linked with
the dynamic (DLL) version of the
run-time libraries. (You should also
avoid mixing the debug and non-debug
versions of the libraries in one
process.)
http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.71).aspx..
The simple answer is no. A more accurate answer is kind of, but you probably wouldn't want to.
It is possible to use Windows Forms (i.e. managed code) for your user interface and something else (e.g. non .NET/unmanaged code) for your domain logic. However I'd guess that if you're asking this question then that is going to be a bit much for you to do at the moment.
I suggest that you create a user interface with Windows Forms and then have that user interface call a native C/C++ DLL. Google for PInvoke on how to call an unmanaged dll (C/C++) from managed (.NET) code.
If you did that then you would be much better positioned to answer this question.
My company software often has to have modules which mix managed and unmanaged code and user interfaces. What we do is to separate the modules into their own executables and expose the functionality as COM localserver objects. This way, the unmanaged code can have a user interface written in managed code.
However, you need to do alot of plumbing to get it to work. We do it this way because our applications have been deployed in the field for years and it will take years to give the entire program a makeover into .NET