靜態庫反編譯
① 如何對一個lib靜態庫保護起來不被反編譯
這個太麻煩了吧，除非他反編譯成匯編，讀懂全部匯編語言，然後用c去實現。逆向工程量太大。我們做一般是加花指令，迷宮函數來混淆代碼。
② 如何看懂lib文件里的東西
想用一個靜態庫必須要裡面函數的聲明，就是頭文件。有些動態庫都需要頭文件呢~沒有頭文件絕對不可能。
完全看懂是不可能的。要是看懂了相當於反編譯了！
如果只要使用，找出一部分函數是有可能的。
你去網上搜索一下「lib 文件結構」
其實可以看到一部分，看到一些函數，你用記事本打開lib。可以看到
xxx@yyy@@zzz 之類的東西。
zzz代表函數名，yyy代表該函數所在的類名，zzz代表參數類型。
可以猜到一部分`~，這個是C++寫成的庫，c語言寫的庫是沒有類名和參數名的（因為不支持類也不支持重載）。
你再把相映的頭文件自己補寫上，
再#include "頭文件"
#pragma comment(lib,"lib文件");
祝你好運了~~
③ cocos2dx-3.6的luajit怎麼了
cocos2d-x中luajit的使用
新版本的cocos2d-x使用了luajit來替代原始的lua，好處一是可以極大的提高運行速度（android下可以開jit，運行速度提高10~60倍，ios下不可以開jit，運行速度也可以提高2~3倍）。 二是luajit編譯的位元組碼現階段來說無法反編譯，也就是說無法破解。 這里對luajit進行詳細的說明。
1、基本使用。這個很簡單，不用修改任何代碼，與lua5.1完全兼容。 對應的頭文件和庫要替換成luajit的(與lua命名相同)
2、發布時編譯成位元組碼。
這個需要luajit.exe的執行文件。 編譯方法(windows)： 在（http://luajit.org/download.html）下載源代碼，使用vs的命令行工具，執行msvc.bat進行編譯。 我最開始使用cygwin直接執行make結果出了很多編譯錯誤和詭異的問題。 其實直接使用批處理才是正確的方式。
編譯完成後，要注意luajit.exe和源代碼src/jit文件夾要同時並且匹配使用。否則運行時會出現 "unknown luaJIT command or jit.* moles not installed"的錯誤。
編譯成位元組碼的命令如下: luajit -b 原始文件 輸出文件
更多詳細說明可以直接執行 luajit -b來獲取。 這里還要注意，輸出文件最好保持.lua的擴展名，否則require文件的時候會提示找不到文件。除非require裡面使用的完整名字。
我在編譯位元組碼時還碰到了一個問題，就是無論編譯什麼文件都提示這個 "luajit '=' expected near '<eof>'" ，後來換了luajit的版本後就沒有出現了。可能跟我一開始手欠改了luajit源代碼有關。
3、編譯luajit的靜態庫文件（for android）
編譯位元組碼所用的執行文件和我們開發程序時使用的靜態庫文件要保持版本一致。 windows版本所需要的文件在編譯執行文件時就已經生成。
④ 用C做的靜態庫，能破解成C語言嗎
目前沒有技術可以把C和C++編譯出的機器語言反編譯成源程序
但是可以反編譯成匯編程序，這個叫反匯編。
因此：用C做的靜態庫，不能破解成C語言
⑤ 如何在android studio中用JNI調用靜態庫
androidstudiondk調用過程如下：通過jniaes案例說明調用NDK層配置過程而我們通過底層來判斷簽名是否正確，如果正確則繼續執行核心代碼，否則退出程序，這樣就可以防止別人惡意反編譯，並進行二次打包。首先去官網下載一個最新的NDK，隨便放到哪都行，像我放在D:\Dev\Android\android-ndk-r10d.(1)新建一個項目：名稱JniAes首先在java類中添加native介面，注意寫好native介面和System.loadLibrary()即可。代碼如下：();();(Contextcontext);4然後buildproject得到其中中間文件，我們關注的是.class文件。編譯OK以後生成的class文件在AS工程的如下目錄：aes\app\build\intermediates\classes\debug\android\（2）接下來跟class文件生成相應的.h頭文件，執行如下命令即可點擊"View->ToolWindows->Terminal"即在Studio中進行終端命令行工具.執行如下命令生成c語言頭文件.javah-djni-classpathc:\Users\sodinochen\AppData\Local\Android\sdk\platforms\android-16\android.jar;..\..\build\intermediates\classes\debugcom.aes.jniaes.MainActivity（3）然後將剛才的.h文件剪切過來。在jni目錄下新建一個c文件，隨意取名，我的叫strk.c。strk.c文件，用於實現核心代碼邏輯，判斷包名.哈希值是否合法，如果返回1，為合法。反之，則不合法。入口方法為：jintJava_com_aes_jniaes_MainActivity_jniCheckAPP(JNIEnv*env,jobjectcontext, jobjectthiz)接下來在工程的local.properties文件中添加NDK路徑（上面下載好的那個NDK），類似其中的SDK路徑一樣，我的添加後如下：sdk.dir=D\:\\Dev\\Android\\android-sdk-windowsndk.dir=D\:\\Dev\\Android\\android-ndk-r10d（4）接下來在appmole目錄下的build.gradle中設置庫文件名（生成的so文件名）。找到gradle文件的defaultConfig這項，在裡面添加如下內容：defaultConfig{ applicationId"com.aes.jniaes" minSdkVersion15 targetSdkVersion22 versionCode1 versionName"1.0" ndk{ moleName"checkapp-jni" //生成的so名字 abiFilters"armeabi","armeabi-v7a","x86" //輸出指定三種abi體系結構下的so庫。目前可有可無。 } }（5）最後就是添加靜態初始化loadLibrary代碼，添加如下：static{ System.loadLibrary("checkapp-jni"); //so文件的名字 }編譯出來的so文件在aes\app\build\intermediates\ndk\debug\lib目錄下 那麼如何將編譯好的so文件進行使用，可以通過如下方式：二. 引用so文件（1）.在「src/main」目錄中新建名為「jniLibs」的目錄；（2）.將so文件復制、粘貼到「jniLibs」目錄內。
⑥ ios 本地工程載入自定義動態庫時，需要對動態庫進行簽名嗎
DLL文件(Dynamic Linkable Library 即動態鏈接庫文件)，是一種不能單獨運行的文件，它允許程序共享執行特殊任務所必需的代碼和其他資源 比較大的應用程序都由很多模塊組成，這些模塊分別完成相對獨立的功能，它們彼此協作來完成整個軟體系統的工作。可能存在一些模塊的功能較為通用，在構造其它軟體系統時仍會被使用。在構造軟體系統時，如果將所有模塊的源代碼都靜態編譯到整個應用程序 EXE 文件中，會產生一些問題：一個缺點是增加了應用程序的大小，它會佔用更多的磁碟空間，程序運行時也會消耗較大的內存空間，造成系統資源的浪費；另一個缺點是，在編寫大的 EXE 程序時，在每次修改重建時都必須調整編譯所有源代碼，增加了編譯過程的復雜性，也不利於階段性的單元測試。 Windows 系統平台上提供了一種完全不同的較有效的編程和運行環境，你可以將獨立的程序模塊創建為較小的 DLL 文件，並可對它們單獨編譯和測試。在運行時，只有當 EXE 程序確實要調用這些 DLL 模塊的情況下，系統才會將它們裝載到內存空間中。這種方式不僅減少了 EXE 文件的大小和對內存空間的需求，而且使這些 DLL 模塊可以同時被多個應用程序使用。Windows 自己就將一些主要的系統功能以 DLL 模塊的形式實現。 一般來說，DLL 是一種磁碟文件，以.dll、.DRV、.FON、.SYS 和許多以 .EXE 為擴展名的系統文件都可以是 DLL。它由全局數據、服務函數和資源組成，在運行時被系統載入到調用進程的虛擬空間中，成為調用進程的一部分。如果與其它 DLL 之間沒有沖突，該文件通常映射到進程虛擬空間的同一地址上。DLL 模塊中包含各種導出函數，用於向外界提供服務。DLL 可以有自己的數據段，但沒有自己的堆棧，使用與調用它的應用程序相同的堆棧模式；一個 DLL 在內存中只有一個實例；DLL 實現了代碼封裝性；DLL 的編制與具體的編程語言及編譯器無關。 在 Win32 環境中，每個進程都復制了自己的讀/寫全局變數。如果想要與其它進程共享內存，必須使用內存映射文件或者聲明一個共享數據段。DLL 模塊需要的堆棧內存都是從運行進程的堆棧中分配出來的。Windows 在載入 DLL 模塊時將進程函數調用與 DLL 文件的導出函數相匹配。Windows 操作系統對 DLL 的操作僅僅是把 DLL 映射到需要它的進程的虛擬地址空間里去。DLL 函數中的代碼所創建的任何對象（包括變數）都歸調用它的線程或進程所有。 調用方式： 1、靜態調用方式：由編譯系統完成對 DLL 的載入和應用程序結束時 DLL 卸載的編碼（如還有其它程序使用該 DLL，則 Windows 對 DLL 的應用記錄減1，直到所有相關程序都結束對該 DLL 的使用時才釋放它，簡單實用，但不夠靈活，只能滿足一般要求。 隱式的調用：需要把產生動態連接庫時產生的 .LIB 文件加入到應用程序的工程中，想使用 DLL 中的函數時，只須說明一下。隱式調用不需要調用 LoadLibrary() 和 FreeLibrary()。程序員在建立一個 DLL 文件時，鏈接程序會自動生成一個與之對應的 LIB 導入文件。該文件包含了每一個 DLL 導出函數的符號名和可選的標識號，但是並不含有實際的代碼。LIB 文件作為 DLL 的替代文件被編譯到應用程序項目中。 當程序員通過靜態鏈接方式編譯生成應用程序時，應用程序中的調用函數與 LIB 文件中導出符號相匹配，這些符號或標識號進入到生成的 EXE 文件中。LIB 文件中也包含了對應的 DL L文件名（但不是完全的路徑名），鏈接程序將其存儲在 EXE 文件內部。 當應用程序運行過程中需要載入 DLL 文件時，Windows 根據這些信息發現並載入 DLL，然後通過符號名或標識號實現對 DLL 函數的動態鏈接。所有被應用程序調用的 DLL 文件都會在應用程序 EXE 文件載入時被載入在到內存中。可執行程序鏈接到一個包含 DLL 輸出函數信息的輸入庫文件(.LIB文件)。操作系統在載入使用可執行程序時載入 DLL。可執行程序直接通過函數名調用 DLL 的輸出函數，調用方法和程序內部其 它的函數是一樣的。 2、動態調用方式：是由編程者用 API 函數載入和卸載 DLL 來達到調用 DLL 的目的，使用上較復雜，但能更加有效地使用內存，是編制大型應用程序時的重要方式。 顯式的調用： 是指在應用程序中用 LoadLibrary 或 MFC 提供的 AfxLoadLibrary 顯式的將自己所做的動態連接庫調進來，動態連接庫的文件名即是上面兩個函數的參數，再用 GetProcAddress() 獲取想要引入的函數。自此，你就可以象使用如同本應用程序自定義的函數一樣來調用此引入函數了。在應用程序退出之前，應該用 FreeLibrary 或 MFC 提供的 AfxFreeLibrary 釋放動態連接庫。直接調用 Win32 的 LoadLibary 函數，並指定 DLL 的路徑作為參數。LoadLibary 返回 HINSTANCE 參數，應用程序在調用 GetProcAddress 函數時使用這一參數。GetProcAddress 函數將符號名或標識號轉換為 DLL 內部的地址。程序員可以決定 DLL 文件何時載入或不載入，顯式鏈接在運行時決定載入哪個 DLL 文件。使用 DLL 的程序在使用之前必須載入（LoadLibrary）載入DLL從而得到一個DLL模塊的句柄，然後調用 GetProcAddress 函數得到輸出函數的指針，在退出之前必須卸載DLL(FreeLibrary)。 正因為DLL 有佔用內存小，好編輯等的特點有很多電腦病毒都是DLL格式文件。但不能單獨運行。 動態鏈接庫通常都不能直接運行，也不能接收消息。它們是一些獨立的文件，其中包含能被可執行程序或其它DLL調用來完成某項工作的函數。只有在其它模塊調用動態鏈接庫中的函數時，它才發揮作用。 dll和內存管理 在Win32中，DLL文件按照片段（sections）進行組織。每個片段有它自己的屬性，如可寫或是只讀、可執行（代碼）或者不可執行（數據）等等。 DLL代碼段通常被使用這個DLL的進程所共享；也就是說它們在物理內存中占據一個地方，並且不會出現在頁面文件中。如果代碼段所佔據的物理內存被收回，它的內容就會被放棄，後面如果需要的話就直接從DLL文件重新載入。 與代碼段不同，DLL的數據段通常是私有的；也就是說，每個使用DLL的進程都有自己的DLL數據副本。作為選擇，數據段可以設置為共享，允許通過這個共享內存區域進行進程間通信。但是，因為用戶許可權不能應用到這個共享DLL內存，這將產生一個安全漏洞；也就是一個進程能夠破壞共享數據，這將導致其它的共享進程異常。例如，一個使用訪客賬號的進程將可能通過這種方式破壞其它運行在特權賬號的進程。這是在DLL中避免使用共享片段的一個重要原因。 當DLL被如UPX這樣一個可執行的packer壓縮時，它的所有代碼段都標記為可以讀寫並且是非共享的。可以讀寫的代碼段，類似於私有數據段，是每個進程私有的並且被頁面文件備份。這樣，壓縮DLL將同時增加內存和磁碟空間消耗，所以共享DLL應當避免使用壓縮DLL。[1][2] [3]找到DLL文件地址：C:\WINDOWS\system32\****.dll時出錯(****就是你的那個找不到的文件名) 開始－－運行－－msconfig－－啟動－－找到和你說的類似的選項****－－取消勾－－確定，然後 1，開始－運行－輸入：regedit，然後回車 2，選擇「我的電腦」，然後點擊「文件」－「導出」－隨便起個名字點「保存」。這樣做的目的是備份一下注冊表，以免誤操作後及時恢復。恢復的方法是，找到你剛才保存的文件，雙擊它，然後選擇「允許導入」即可。 3，選擇「我的電腦」，按F3鍵，然後輸入「****」，點擊「查找下一個」，找到後一定要核對是不是****.dll文件，因為你給的文件名不全，如果確認，對該項點「右鍵」選「刪除」。「此時可以輸入****.dll進行查找，結果出來後要看後面的數值部分，不能光看文件名稱，只要有****.dll在的文件不管它邊上還寫沒寫別的（如：****.dll，load），都要刪除！」 4，然後再按F3鍵－刪除，直到提示「沒有找到相應選項」為止。 5，重新啟動計算機，看看系統有沒有問題。 注，如果出現了其它嚴重問題，請恢復注冊表。
⑦ 呃，請問怎麼修改單機游戲的編程碼
修改運行的PC游戲，這個最簡單，有《金山游俠》《FPE》《GB4》等修改工具。。。
要修改游戲程序代碼，這個就難了，你得懂匯編，編譯原理，編譯流程，各種PE執行文件或其他執行文件或代碼的數據結構，各種靜態庫以及動態鏈接庫的結構，等等。。。一系列編程知識，而且還得具備一定的硬體知識，以及操作系統知識。。。然後用反編譯工具把游戲的執行文件以及庫文件反編譯，將執行文件或代碼反編譯成匯編代碼，更好一些的反編譯工具能把代碼反編譯成C/C++代碼，只是這些代碼完全沒有變數命名，所有變數都用A1、B1這樣的。。。然後根據程序執行來猜某塊代碼的大致作用，然後再將代碼完全讀懂，最後才能修改代碼。。。這個。。。非常困難，就是職業程序員高手，並且已經具備了我上面說的一切知識以及技能，也非常難。。。因為反編譯程序，極度欠缺可讀性，有些宏以及編譯系統的偽指令擴展後，反編譯出來的代碼非常難讀懂。。。這必須要是專業干這個的，對編譯系統足夠了解，並且習慣了反編譯代碼的那類專業人士才能真正的干好這件事。。。總之這是件極度專業的事情。
⑧ ios a靜態庫 能反編譯嗎
.a靜態庫不能進行反編譯，反匯編的可能性也極低。
靜態庫：靜態庫僅在程序啟動時被連接使用，程序運行時將不再需要該靜態庫。
與靜態庫相對的是動態庫：程序編譯時並不會被連接到目標代碼中，而是在程序運行是才被載入，因此在程序運行時還需要動態庫存在。
⑨ 有關於Visual Studio 2005 EXE程序反編譯成可用代碼的問題~！~
你應該選擇使用靜態庫啊。動態庫你要運行必須連相關的dll一起拷貝到別人電腦上去！
還有一些特別的情況，雖然是針對VC2005的，但是對VC6也有參考價值。
前面一些是我在網上找的，後面的有些是我自己現添加的，希望對你有幫助！
報錯"由於應用程序配置不正確,應用程序未能啟動.重新安裝應用程序可能會糾正這個問題"
//------------------------------------------------------
這個問題主要出現在XP環境下運行由Visual C++2003/2005編譯的MFC程序時
問題現象是XP運行此類程序時,報錯"由於應用程序配置不正確,應用程序未能啟動.重新安裝應用程序可能會糾正這個問題"
這個問題似乎許多人遇見過.在CSDN和微軟社區裡面都有人提到.但是沒有完整的解決方案
這個問題的解決一共會遇見2個子問題
最早出現這個錯誤我和許多人認為的一樣
認為是缺乏DLL庫文件導致.但是在測試機復制了DLL甚至安裝了.net framework 2.0以後
都無法解決問題,最後確認不是由缺乏DLL所致
因為程序是純win32的應用程,非託管代碼,所以也無需.net framework
Visual C++2003/2005默認的MFC程序是使用動態MFC庫(Use MFC in a Shared DLL)來鏈接的
而動態MFC庫使用的是Multi-threaded DLL (/MD)
由於XP對於PE文件格式監測更加嚴格.
就會導致部分使用多線程DLL的可執行文件在調用的時候出錯
修改項目屬性的編譯開關
Project->Property->configuration Properties->C/C++->Code Generation->Runtime Library
修改成Multi-threaded (/MT)
修改了Runtime類型以後
需要將MFC的編譯類型也改成靜態庫
Project->Property->configuration Properties->General->Use of MFC
修改成Use MFC in a Static Library
一部分情況下在這步就能解決問題
另外一部分情況會遇見如下情況
編譯器報錯
CODE:
nafxcw.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in libcpmt.lib(newaop.obj)
[Copy to clipboard]
產生這個問題的原因是庫依賴關系
在Project->Property->configuration Properties->Linker->Command Line
加入編譯開關/verbose:lib可以顯示詳細的庫鏈接順序
CODE:
------ Build started: Project: PerfMonDemo, Configuration: Release Win32 ------
Linking...
Searching libraries
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\pdh.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\DelayImp.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\libcpmt.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\nafxcw.lib:
nafxcw.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in libcpmt.lib(newaop.obj)
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\libcmt.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\kernel32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\user32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\gdi32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\msimg32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\comdlg32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\winspool.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\advapi32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\shell32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\comctl32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\shlwapi.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\uuid.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\oledlg.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\ole32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\oleaut32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\urlmon.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\OLDNAMES.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\atls.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\ws2_32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\mswsock.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\oleacc.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\pdh.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\DelayImp.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\libcpmt.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\nafxcw.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\libcmt.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\kernel32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\user32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\gdi32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\msimg32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\comdlg32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\winspool.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\advapi32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\shell32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\comctl32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\shlwapi.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\uuid.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\oledlg.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\ole32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\oleaut32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\urlmon.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\OLDNAMES.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\atls.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\ws2_32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\mswsock.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\oleacc.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\pdh.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\DelayImp.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\libcpmt.lib:
Finished searching libraries
Searching libraries
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\pdh.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\DelayImp.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\libcpmt.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\nafxcw.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\libcmt.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\kernel32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\user32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\gdi32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\msimg32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\comdlg32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\winspool.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\advapi32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\shell32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\comctl32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\shlwapi.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\uuid.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\oledlg.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\ole32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\oleaut32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\urlmon.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\OLDNAMES.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\atls.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\ws2_32.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\mswsock.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\oleacc.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\pdh.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\DelayImp.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\libcpmt.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\nafxcw.lib:
Finished searching libraries
.\Release/PerfMonDemo.exe : fatal error LNK1169: one or more multiply defined symbols found
Build log was saved at "file://d:\Dev\Performance Monitor\Release\BuildLog.htm"
PerfMonDemo - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
[Copy to clipboard]
我們發現在libcpmt.lib聲明過的operator new在nafxcw.lib中再次定義
解決方法如下
Project->Property->configuration Properties->Linker->Input->Additional Dependencies
加入
nafxcw.lib
libcpmt.lib
Project->Property->configuration Properties->Linker->Input->Ignore Specific Library
加入
nafxcw.lib
libcpmt.lib
這樣鏈接程序就不會先按照默認順序來連接這兩個庫文件
而是在最後在加入對他們的引用.這樣就避免了這個問題
下面是一張可能發生沖突的列表
若要使用此運行時庫 請忽略這些庫
單線程 (libc.lib) libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
多線程 (libcmt.lib) libc.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
使用 DLL 的多線程 (msvcrt.lib) libc.lib、libcmt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
調試單線程 (libcd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcmtd.lib、msvcrtd.lib
調試多線程 (libcmtd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、msvcrtd.lib
使用 DLL 的調試多線程 (msvcrtd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib
//本人曾經對上面的方法進行測試，修改後可能出現XX無法解析的情況，請大家使用MSDN查找該函數，並且找到該函數對應的lib庫文件。將其添加到附加依賴項或者是用#pragma comment(lib,"xxx.lib")將其添加到代碼中！