关于.lib文件，.dll文件，后期绑定，嵌入式应用程序的基本问题？

Question

过去4个月我开始使用OpenCV和OpenSceneGraph等第三方库，我有一些基本的问题......

1。）当我们使用任何函数时，我们程序中提到的lib文件（包含函数）（例如-lcv.lib，-lhighgui.lib）依次调用bin中的相应.dll文件文件夹？这个调用是在运行时进行的吗？

2.）使用CMAKE，MAKE和Visual Studio解决方案文件，源代码中的lib文件和dll文件的静态构建和动态构建之间的区别是什么？

3.）使用.dll只是为了减少可执行代码的大小？

4.）嵌入式视觉应用程序（或使用库的任何嵌入式应用程序）是在处理器/控制器/芯片中转储的整个可执行代码吗？嵌入式应用程序中是否存在后期绑定或运行时调用的概念？

请对这些问题有所了解，以便我能够理解我在代码中使用的内容......还是提前...

Answer 1

  

1。）当我们使用任何函数时，我们提到的lib文件（包含函数）（例如-lcv.lib，-lhighgui.lib）   程序依次调用bin中找到的各个.dll文件   文件夹？这个调用是在运行时进行的吗？

是的，libs只包含链接器能够解析exe中寻址的函数的信息。实际代码在运行时加载。

  

2.）使用CMAKE，MAKE和来自源代码的lib文件和dll文件的静态构建和动态构建之间的区别是什么   Visual Studio解决方案文件？

没有，visual studio只是让它更方便（主观）。

  

3.）使用.dll只是为了减少可执行代码的大小？

可以（如果与先前版本兼容，例如接口未更改）更改dll内容而无需重新创建exe。

一个人也可以延迟加载库（即不与.lib文件链接，而是使用LoadLibrary / GetProcAddress），因此可以在dll中具有可选功能，如果它在那里启用但仍然能够如果找不到dll，则运行。

  4.）嵌入式视觉应用程序（或使用库的任何嵌入式应用程序）是转储的整个可执行代码   处理器/控制器/芯片？有任何后期绑定或概念的概念   嵌入式应用程序中的运行时调用？

它取决于操作系统，通常（至少在我迄今为止参与的嵌入式项目中）使用静态库，因为嵌入式设备上的操作系统不支持共享库。如果操作系统支持它，那么很好，但嵌入式设备上的硬件/软件通常非常有限。

Answer 2

是的，重点是消除重复，这样您就没有100个应用程序都拥有内置于其可执行文件中的同一个库的副本。从理论上讲，这也可以在一个地方完成对库的更新，而不是更新100个应用程序。

动态链接是操作系统支持的功能。所以答案取决于您在嵌入式系统上运行的操作系统。许多嵌入式目标都运行Linux，因此在这种情况下，您具有与PC上完全相同的行为。

微控制器上常见的较小操作系统通常不支持动态链接。

Answer 3

dll是在你的应用程序的开始时间默认加载的，但是你可以手动更改它加载dll（不记得它是如何工作的，但它有点无聊）。 静态构建意味着您需要的所有opencv函数都在.exe文件中，而不是在您机器上的某个位置。

我认为对于真正的嵌入式应用程序，最好使用静态链接，因为通常只有一个程序运行。 在你的机器上你将有20个使用opencv的程序，所以如果你让它们动态加载dll它应该在你的机器上节省大量内存。由于opencv每3个月更改一次，我认为最好将opencv作为静态链接进行分发。对于一个大型程序，它更有意义....

Answer 4

您可以将代码编译为一个巨大的可执行文件，将所有模块复制到自身中，或者将它们编译为一个小的可执行文件和一组以DLL或共享库形式的可动态加载的模块。共享库/ DLL使您的可执行代码模块化，可维护，并允许可执行代码的可重用性，从而使您的可执行文件更加纤薄。您可以独立且轻松地将修复程序发送到动态模块，而无需触及主要可执行文件。此外，许多可执行文件可以在运行时共享和加载相同的DLL /共享库，从而允许可重用​​性并减少磁盘空间需求。

现在，您的动态模块可能会使用其他第三方库，这些库可能会再次作为动态模块本身发送。这意味着无论何时引用动态模块，系统都会尝试查找并解析它所依赖的模块。因此，它是一个依赖性解决链。

据我所知，嵌入式系统使用小型嵌入式操作系统。您可以将应用程序发送到操作系统可以参考的某种内存上;可能是可插拔磁盘驱动器或嵌入式存储设备或其他东西，具体取决于嵌入式系统的复杂程度。如果操作系统支持动态加载共享模块，那么您可以将应用程序作为一组可执行和动态模块发送。