我開始使用第三方庫，如OpenCV和OpenSceneGraph過去4個月，我有一些基本問題...關於.lib文件，.dll文件，後期綁定，嵌入式應用程序的基本問題？
1.）當我們使用任何函數時，我們提到的lib文件（包含函數） （例如-lcv.lib，-lhighgui.lib）在我們的程序中依次調用bin文件夾中的相應.dll文件？此調用是否在運行時發生？
2）什麼靜態的構建和從源代碼中使用cmake，使LIB文件和dll文件和Visual Studio解決方案文件的動態構建之間的區別？
3.）是否僅使用.dll來減少可執行代碼的大小？
4.）在嵌入式視覺應用（或利用庫中的任何嵌入式應用）是在處理器/控制器/芯片傾倒整個可執行代碼？是有嵌入式應用後期綁定或運行時調用的任何概念？
請給一些有識之士對這些問題，這樣我可以瞭解什麼我使用的代碼... thanx提前裏想的......
1）當我們使用任何功能確實是我們提到的lib文件（包含函數）（例如-lcv.lib，-lhighgui.lib）在我們的 程序依次調用相應的.dll文件在bin 文件夾中找到？此調用是否在運行時發生？
是的，這些庫僅包含鏈接器能夠解析exe文件中的函數的信息。實際的代碼在運行時加載。
2）什麼靜態構建和從源代碼中使用cmake，製造和 Visual Studio解決方案文件的lib文件和dll文件的動態構建之間的區別？
沒有，視覺工作室只是使它更方便（主觀）。
3.）是否只是爲了減少可執行代碼的大小而使用.dll的好處？
它有可能（如果兼容以前的版本，例如界面沒有改變）來改變dll內容而不重新創建exe。
也可以延遲加載庫（即不與一個.lib文件鏈接，而是使用LoadLibrary/GetProcAddress）在稍後的點，因此可以有一個DLL中的可選功能，如果它有啓用但仍然能夠運行如果沒有找到DLL。
4.）在嵌入式視覺應用（或使用的庫）的嵌入式應用是在 處理器/控制器/芯片傾倒整個可執行代碼？是有後期綁定或 運行時調用的在嵌入式應用中的任何概念？
它依賴於操作系統，通常（至少在迄今爲止涉及的嵌入式項目中）使用靜態庫，因爲嵌入式設備上的操作系統不支持共享庫。如果操作系統支持它，那麼很好，但嵌入式設備上的硬件/軟件通常非常有限。
沒錯，關鍵是要消除重複，這樣你不要」沒有100個應用程序都具有內置在其可執行文件中的相同庫的副本。理論上，這也將允許在一個地方更新庫，而不是更新100個應用程序。
動態鏈接是操作系統支持的功能。所以答案取決於您在嵌入式系統上運行的操作系統。許多嵌入式目標都在運行Linux，因此在這種情況下，您的行爲與PC上的行爲完全相同。
微控制器上常見的較小OS通常不支持動態鏈接。
的DLL是每默認在您的應用程序的啓動時加載的，但你可以改變它手動加載動態鏈接庫（唐噸記得它是如何工作，但它是一個有點無聊）。 靜態構建意味着您需要的所有opencv函數都位於.exe文件中，而不是您計算機上的某處。
我要說真正的嵌入式應用最好是使用靜態鏈接，因爲你通常只是一個PROGRAMM運行。 在你的機器上你將有20個使用opencv的程序，所以如果你讓它們動態地加載dll，它應該會在你的機器上節省大量的內存。由於opencv每3個月更改一次，我認爲最好將opencv作爲靜態鏈接進行分發。對於一個大PROGRAMM更有意義....
但您可以編譯代碼無論是作爲一個單一的巨大的可執行文件，它會將所有的模塊到自身，或將它們編譯爲一個小的可執行文件和一組動態可加載模塊以DLL或共享庫的形式。共享庫/ DLL使您的可執行代碼模塊化，可維護，並允許可執行代碼的可重用性，從而使您的可執行代碼更加小巧。您可以獨立且輕鬆地將修補程序發送到動態模塊，而無需觸摸主要的可執行文件。此外，許多可執行文件可以在運行時共享和加載相同的DLL /共享庫，從而允許重用和減少磁盤空間要求。
現在，您的動態模塊可以使用其他可能被再次運動態模塊本身的第三方庫。這意味着無論何時引用動態模塊，系統都會嘗試查找並解析它所依賴的模塊。因此，它是一個依賴關係解決方案鏈。
據我所知，嵌入式系統使用一個小型的嵌入式操作系統。您可以將應用程序發佈到操作系統可以參考的某種內存上;這可能是一個可插拔的磁盤驅動器或嵌入式內存設備或其他東西，這取決於嵌入式系統的複雜程度。如果操作系統支持共享模塊的動態加載，那麼您可以將應用程序作爲一組可執行模塊和動態模塊來運送。