|
|
Good 
I found your question in the OpenCV forum and see that you are building the static libs yourself (that was going to be my next question).
I have not worked with statically linked OpenCV myself, but you listed the libs you added to your project and go on to say that it seems to link all the libs, not just the ones you added. I agree this is most likely your problem. Did you by chance have a path set up under your projects "Library Directories" that you did not remove?
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
I have double checked to make sure all the path's and lib's setup in the Project Properties are correct.
I am not sure whether the size of the final exe is because it's linking all lib's.
Like Richard in his response said, maybe the Visual Studio compiler links in all lib's that it deems necessary to run the exe.
|
|
|
|
|
Don Guy wrote: Like Richard in his response said, maybe the Visual Studio compiler links in all lib's that it deems necessary to run the exe.
Well, Richard's point is that it only links what it needs, not that it goes searching for more than you are "pointing to".
Is it possible for you to comment out all the OpenCV you use and build the application without linking to it? I was just curious to see how large it is without any of the OpenCV.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
If i remove the Static Link option from the Project Properties and build, then the exe is 100 KB.
With the Static Link option in, it's about 6.1 MB.
If i leave the Static Option in and just comment out the code, i.e., #include's and other OpenCV references, then am not sure how much it's going to be. I will check that out later.
Does that test tells anything?
|
|
|
|
|
Yes, it tells me that not only are you statically linking the OpenCV libraries, you are also statically linking MFC, right?
I found a post earlier by a developer from the Visual C++ Libraries team. Go through that and see if putting that #define in your stdafx.h can help you out.
http://blogs.msdn.com/b/vcblog/archive/2012/02/06/10263387.aspx[^]
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
modified 6-Feb-14 0:18am.
|
|
|
|
|
With Static Linking options in, i.e., in Configuration Properties --> General --> Use of MFC = Use MFC in a Static Library, and then comment out all OpenCV code in the app, the total exe size is 4 MB. So basically it reduced 2 MB, but no significant difference.
I added the #define _AFX_NO_MFC_CONTROLS_IN_DIALOGS to stdafx.h file and that didn't make any difference.
Btw, i am using Visual Studio 2012.
|
|
|
|
|
|
I posted the first of those and the response was pretty much a giant shrug from Microsoft. They did reduce the static link size a little in VS 2012, but they are still big. Unless the program in question has to be small for whatever reason, I'd go the dynamic link route. If it has to be small, you may have to go back to an earlier version of VS 2008.
(I never did update that project to VS 2010 because of this.)
|
|
|
|
|
Thanks for responding. Do you know if you can reduce the size by targeting an older version of MFC in the project settings? I am not sure that would be a good idea, but I was wondering if that would make a difference.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
The workarounds say you can target an earlier version and it helps. Makes sense since the problem is with too many cross dependencies in MFC.
|
|
|
|
|
How to link statically to OpenCV?
For dynamically linking to MFC, do i select, "Use of MFC = Use MFC in a Shared DLL"?
Right now for statically linking OpenCV i got,
Linker --> General --> Additional Library Directories = C:\opencv\install\x64\vc11\staticlib
Linker --> Input --> Additional Dependencies = "List all Lib's"
Am i missing something here?
|
|
|
|
|
That is exactly how you do it. By listing the OpenCV lib files under Linker|General|Additional Dependencies, they get linked in statically and you don't need to ship the application with the DLLs.
Yes, setting "Use MFC in a Shared DLL" gives you the dynamic linking to MFC I suggest, but the MFC DLLs have to be on your client's machine - there is a very good chance they already are.
This gives you that nice 100 KB exe you got here[^]. The fact that you did not mention any linker errors is a very good sign.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
Well, am getting linker errors now, that too plenty of them.
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'
The OpenCV library am trying to link is build as Static Release, but the MFC is now Dynamic.
Any ideas?
|
|
|
|
|
The /MD /MT options are used for specifying how the Runtime Libraries[^] are linked. Note that this is not the MFC stuff.
You should be able to rebuild the OpenCV libraries with the /MD switch instead of /MT. I think that will cause you the least trouble going forward.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
If i am right, /MD = Dynamic and /MT = Static.
If i build OpenCV as /MD and then link to the MFC app, during run time it will ask for OpenCV dll's.
|
|
|
|
|
I don't know the details of building the OpenCV libraries. I know there is a BUILD_SHARED_LIBS flag, but I don't know if you can set that to OFF (like you have done) and somewhere else specify the /MD switch and have it correctly build all the lib files without a dependency on the DLLs.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
I created a WIN32 console application and statically linked the OpenCV. The final exe is little less than 4 MB.
This kinda proves that there's a overhead when using MFC with statically linked lib's.
For my purpose this works fine, as the OpenCV will ultimately be running in a WIN32 DLL.
Thanks SoMad for your suggestions!
Now the next part am working on is adding an XML file to the project and compiling it into the project.
|
|
|
|
|
 It sounds like you are making progress.
There is another approach to this and that is how I often deal with these kind of scenarios where I need to include 3rd party libraries (like Live555 and FFmpeg), but I want to reduce the number of distributable files and the interdependency of those files. Since you just mentioned the WIN32 DLL, this might also be what you are planning on doing in the end.
Instead of just building the EXE and distributing that, I build the EXE and a DLL for interfacing to the 3rd party library. That way I can tailor the DLL to work with the 3rd party library according to my needs, while compiling the library according to its needs.
You should be able to build your DLL with the /MT setting and build your EXE with the /MD and Shared MFC DLL setting then dynamically load the DLL.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
Don Guy wrote: Now the next part am working on is adding an XML file to the project and compiling it into the project.
I assume you are putting it in the resource.
XResFile - Files Stored in Resources: Part 1 - Text and Binary[^]
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
I have a Windows dialog-based application here. I have a button that calls ChooseColor() to let the user select a new color for the program. However, when I click the button, the color dialog opens, but the mouse and keyboard appear to be completely ignored on it.
I've never seen this happen before, does anyone know what could cause this?? The relevant code is included below.
//****************************************************************
static int select_color(HWND hwnd, COLORREF old_attr)
{
static CHOOSECOLOR cc ;
static COLORREF crCustColors[16] ;
// init-int this array did not affect the mouse problem
// uint idx ;
// for (idx=0; idx<16; idx++) {
// crCustColors[idx] = RGB(idx, idx, idx) ;
// }
ZeroMemory(&cc, sizeof(cc));
cc.lStructSize = sizeof (CHOOSECOLOR) ;
cc.rgbResult = old_attr ;
cc.lpCustColors = crCustColors ;
cc.Flags = CC_RGBINIT | CC_FULLOPEN ;
// cc.hwndOwner = hwnd ; // this hangs parent, as well as me
if (ChooseColor(&cc) == TRUE) {
return (int) cc.rgbResult ;
} else {
return -1 ;
}
}
//******************************************************************
case WM_COMMAND: // for keyboard handling
{ // create local context
DWORD cmd = HIWORD (wParam) ;
DWORD target = LOWORD(wParam) ;
switch (cmd) {
case BN_CLICKED:
switch(target) {
case IDB_ATTR_SET:
result = select_color(hwnd, test_init.set_bit) ;
if (result >= 0) {
// do something with the value
}
break;
} //lint !e744 switch target
return true;
} //lint !e744 switch cmd
//************
Later note: I created a stripped-down version of this application, which demonstrates this issue. I don't see any way to attach a file here, but the package can be downloaded from my website:
home.comcast.net/~derelict/files/ChooseColor.hang.zip
This is built using MinGW toolchain. It has been tested on multiple Win7/64bit and WinXP/SP3/32bit machines, all showing the same behavior.
|
|
|
|
|
I just tried the above code and it works fine.
Veni, vidi, abiit domum
|
|
|
|
|
Huh?!?!?
You can select cells in the color dialog, and the cancel/okay buttons work??
That's bizarre...
Did you build with MinGW ? If so, what version? (though I don't think that matters)...
I also went back to another small dialog-based application that I wrote some time ago, and pasted the select_color() function into it and called it from a button, and that worked fine as well.
This is really twisting my brain in a knot !!!!!
|
|
|
|
|
Derell Licht wrote: Did you build with MinGW ?
No, just standard Win32 code. I suspect there is something else happening in your code that causes this problem.
Veni, vidi, abiit domum
|
|
|
|
|
Please clarify... when you say "I just tried the above code and it works fine.", do you mean you put the code fragment that I printed, in another program and ran it? I was hoping you downloaded and built my sample code... I guess that would be a problem if you don't use MinGW.
I agree that it is something in my code, but I'm damned if I can figure out what !!
I'm comparing the stripped-down failing code against another working Win32 utility that I have (where the button code works fine), and for the life of me I cannot figure out what the difference is!!
What I'm doing now, is I made a copy of the working project, and am pasting pieces of my target project into it, one piece at a time, until I hopefully find what breaks the color dialog. My great fear is that I'll never find it, and the copied project will work fine - and I'll NEVER figure out why this one is broken... 
//************************
Later note: yeah, I got the application completely ported over from the original project to the new project based on a dialog where the ChooseColor() worked properly, and the entire project works fine.
Of course, I can't find any difference between the two, that could explain the original problem. I guess I'll never know...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
