Basic questions about .lib files ,.dll files , late binding , embedded applications?

Question

i started using 3rd Party libraries like OpenCV and OpenSceneGraph for the past 4 months and i have some basic questions...

1.) when we use any function does the lib files (containing the function) which we mention (e.g. -lcv.lib , -lhighgui.lib) in our program in turn call the respective .dll files found in the bin folder?does this call take place at runtime?

2.)whats the difference between static build and dynamic build of the lib files and dll files from the source code using CMAKE,MAKE and Visual Studio Solution files?

3.)is the benefit of using .dll only to reduce the size of the executable code?

4.)in embedded vision applications (or any embedded application using libraries) is the whole executable code dumped in the processor/controller/chip?is there any concept of late binding or runtime call in embedded applications?

Please give some insight to these questions so that i can understand whats going on inside the code i use...thanx in advance...

Answer 1

1.) when we use any function does the lib files (containing the function) which we mention (e.g. -lcv.lib , -lhighgui.lib) in our program in turn call the respective .dll files found in the bin folder?does this call take place at runtime?

yes, the libs contain only information for the linker to be able to resolve the functions addressed in your exe. the actual code is loaded during runtime.

2.)whats the difference between static build and dynamic build of the lib files and dll files from the source code using CMAKE,MAKE and Visual Studio Solution files?

none, visual studio just makes it a bit more convenient (subjectively).

3.)is the benefit of using .dll only to reduce the size of the executable code?

it is possible (if compatible with previous version e.g. interface not changed) to change the dll contents without recreating the exe.

one can also lazy load libraries (i.e. not link with a .lib file and instead use LoadLibrary/GetProcAddress) at a later point and thus one could have optional functionality in a dll and if it is there enable but still be able to run if the dll is not found.

4.)in embedded vision applications (or any embedded application using libraries) is the whole executable code dumped in the processor/controller/chip?is there any concept of late binding or runtime call in embedded applications?

it depends on the OS, often (at least in the embedded projects I have been involved so far) static libs are used because the OS on the embedded device doesn't support shared libraries. if the OS supports it then fine but often the hardware/software on embedded devices is very limited.

Answer 2

Yes, the point is to eliminate duplication such that you don't have 100 applications that all have copies of the same library built into their executable. In theory, this also would allow an update to the library to be done in one place rather than updating 100 applications.

Dynamic linking is a feature supported by operating systems. So the answer depends on what OS you are running on your embedded system. Many embedded targets are running Linux, so in that case you have exactly the same behavior as on a PC.

Smaller OS's common on microcontrollers will usually not support dynamic linking.

Answer 3

the dlls are per default loaded at start time of your application but you can change it loading the dlls manually (don t remember how it worked but it is a bit boring). static build means all opencv function you need are in the .exe file and not somewhere on your machine.

I would say for real embedded applications it is better to use static linking since you have normally just one programm running. On your machine you will have 20 programs using opencv so if you let them load dynamicly the dlls it should save a lot memory on your machine. Since opencv changes every 3 months the version I would say it is better to distribute opencv as static linking. For a big programm it makes more sense....

Answer 4

You can compile your code either as a single huge executable file which copies all the modules into itself, or compile them to a small executable and a set of dynamically loadable modules in the form of DLLs or shared libraries. Shared libs/DLLs make your executable code modular, maintainable and allows reusability of the executable code thus making your execuables more slimmer in size. You can ship fixes to your dynamic modules independenty and easily without touching your main executable. Also, many executables can share and load the same DLL/Shared lib at runtime thereby allowing reusability and reducing disk space requirements.

Now, your dynamic modules may use other 3rd party libraries which may be shipped again as dynamic modules themselves. This means that whenever your dynamic module is referenced the system will try to locate and resolve the modules on which it dependends. Thus, it is a chain of dependency resolution.

As I understand, embedded systems use a small embedded operating system. You may to ship your application on some kind of memory which the OS can reference; which could be a plugable disk drive or embedded memory device or something else, depending on the level of sophistication of your embedded system. If the OS supports dynamic loading of shared modules then ofcourse you can ship your application as a set of executable and dynamic modules.