ue5源碼編譯報sdk沖突

㈠ iOS-集成多個SDK內部文件重復沖突解決

最近使用Hbuilder集成一個項目，集成了很多sdk，發現有兩個sdk都是用了Masonry第三方庫布局，然後編譯報錯，關鍵字： plicate symbol ，出現這個就表示有重復文件了，我們需要把其中的一個sdk文件中生成的重復的.o文件一一刪除即可，如下則為相關位置，我將把Masonry.framework的相關重復文件一一移除合並解決沖突問題。

步驟如下：

1.打開終端cd到所要修改的sdk所載文件目錄(最好備份一個出來，改完再替換)

2.查看靜態庫文件包含的架構：

命令： lipo -info  xxxx.a 

主要看看總共有哪些架構有沖突，後面需要一一從相關架構移除。如下

根據結果可以看出包含armv7 i386 x86_64  arm64 這幾個庫，沖突文件必須從必須從每個架構的庫裡面相應刪除才行，其中x86_64為模擬器的架構，如果不需要模擬器調試，嫌麻煩x86_64可以不管。具體指令集相關可以看這篇文章： https://www.jianshu.com/p/5d1ce5d3d8d6

3.分離出相應架構的庫：

命令： lipo -thin armv7 XYRiskAssessment-iOS-1.0.0.a -output armv7.a

例：lipo -thin armv7 Masonry -output Masonry-armv7

然後我們就可以看到我們的sdk目錄下會多一個Masonry-armv7的庫,如下：

同樣的方法我們可以分離出i386  x86_64   arm64 文件分離完成後如下：

4.查看庫中所包含的文件列表

命令為： ar -t  xxx.a

例： ar -t  Masonry-armv7

5.如果不清楚兩個sdk都有哪些文件重復，可以按照以上步驟，查看下另一個重復的sdk都包含哪些文件，如下所示和Masonry.framework重復的DCUniVideoPublic.framework分離出armv7架構的文件列表，其實也可以在xcode編譯重復信息裡面找到相關.o文件，看個人喜好。

6.接著我們就要從每個架構文件中，刪除相關的沖突.o文件

命令：:ar -d -sv XXXXX-armv7.a  XXXX.o

例：

ar -d -sv Masonry-armv7 MASCompositeConstraint.o

ar -d -sv Masonry-armv7 MASViewConstraint.o

7.最後一步：把armv7 i386  x86_64   arm64 所有架構的重復文件按照上面方法刪除完成後。我們要把這幾個架構合並到原來的庫裡面

和並靜態庫的命令:

lipo -create XXXXX-armv7.a XXXXX-armv7s.a (加上所有架構的編譯庫) -output XXXXX-NOFfmpeg.a

例：

lipo -create Masonry-x86_64 Masonry-armv7 Masonry-i386 Masonry-arm64 -output Masonry

最後將這個新生成的靜態庫文件替換掉之前的，發現沖突解決。

注意：當把Masonry相關沖突.o文件移除後，這個移除合並後的兼容版本是不能單獨拿去使用的，單獨使用以上移除的.o文件會出現丟失的編譯錯誤，因為你已經移除了。

覺得有幫助留個贊再走唄 ～

㈡ ue5點擊窗口和開始沒反應

方法一：卸載沖突軟體

這種情況有可能是存在沖突軟體引起的。如果你確定這種情況是在安裝某個軟體之後出現了，那麼可以嘗試進入安全模式中把這個軟體卸載：

按window+R鍵，彈出運行窗口，輸入msconfig調出系統配置窗口：



1.選擇引導標簽頁，勾選安全引導選項。

2.點擊確定後重啟系統。

3.系統進入安全模式，在安全模式中卸載最近安裝後導致任務欄系統圖標無法點擊的軟體。

4.卸載軟體之後，同樣按照上面的方法調出系統配置窗口，並把安全引導選項勾除。

5.再次重啟系統，看看是否問題解決。

方法二：重啟window資源管理器

如果你排除是因為軟體沖突引起的問題，那麼你可以簡單嘗試下重啟window資源管理器。

1.按Ctrl+Alt+Delete鍵或者右鍵任務欄菜單調出任務管理器。

2.在任務管理器中找到Widnwo資源管理器，右鍵菜單選擇重啟，或者點擊右下角重新啟動按鈕查看情況是否解決。

㈢ 百度sdk和導航的sdk沖突了，怎麼辦

正常安裝情況下不會發生沖突。如果的確有沖突，全部刪除（卸載），
重新安裝，所有參數讓系統自動選擇，應該就不會有沖突了。

㈣ ue5打包效果很差

為了能更新到IOS 15 SDK，我們必須將Xcode也升級到13版本之後。連帶著的，我的Mac系統也得升級到最新版才能支持Xcode13。（蘋果這一套更新流程真的是痛苦）

一切系統、軟體都已經升級完畢。我們滿心歡喜地通過windows進行遠程打包，發現報了一堆variable 「***」 set but not used 的錯誤。

而直接在Mac上通過Xcode編譯空項目時，竟然也報這個錯誤。那基本可以斷定，最新版的xcode編譯條件更加嚴格，「set but not used」這種不算錯誤的錯誤，也被拎出來鞭屍了。

當然，我們可以把沒有使用的變數都注釋掉以規避掉這個問題，但是在開發測試階段，變數又很多的情況下這樣做非常耗時，更不要說有些未使用變數是部分引擎模塊本身就存在的，所以我們還是要解決這個編譯設置的問題。

解決方法有很多，大家擇一而用就好。（推薦方法二、三）

一、使用較低版本的Xcode（適合純小白）--親測可用

Xcode13也是有很多小版本的，經過國內外各位開發者的測試，使用Xcode13.2.1版本你既可以享受最新版本的IOS SDK，你也可以不去管編譯設置導致的錯誤。需要的用戶可以直接使用以下鏈接下載使用。

https://download.developer.apple.com/Developer_Tools/Xcode_13.2.1/Xcode_13.2.1.xip

此方式不需要改代碼，適合小白用戶。但也僅適合小白用戶。因為IOS SDK版本不斷升級，以後我們必然還要使用更新的Xcode14、Xcode15 。。。 使用低版本Xcode只能解決眼下問題。

二、更改Unreal項目設置（適合使用mac編譯的人）--親測可用

用xcode打開項目，我們找到項目中的 .target.cs 和 Editor.target.cs，在其中加入以下兩行

bOverrideBuildEnvironment = true;
AdditionalCompilerArguments = "-Wno-unused-but-set-variable";
記得兩個文件都要改，不要忘記Editor.target.cs。

之後我們重新使用Xcode編譯，便可暢通無阻了。

當然，缺點是如果在windows下添加這兩行進行遠程編譯，這是不起作用的，甚至Visual Studio會報Wno-unused-but-set-variable指令無效阻止你重新編譯項目。

三、修改Unreal引擎文件（適合用windows進行遠程編譯的人） --親測可用

找到Engine/Source/Programs/UnrealBuildTool 目錄，雙擊 UnrealBuildTool.csproj 打開工程（不要求源碼版，Launcer版本也可）

定位到工程的Platform/IOS/IOSToolChain.cs文件

在文檔中搜索關鍵詞 -Wall

我們刪掉-Wall

rebuild一下UnrealBuildTool

關掉UBT工程，重新打開原本的項目，編譯、打包一條龍毫無障礙~

在外面玩了好幾個月，我終於要回到開發生活當中了。

㈤ 請教庫沖突的導致的 plicate symbol 鏈接錯誤

場景：
解決TencentOpenAPI.framework與ZbarSDK中 _base64_encode 函數的沖突
後來在網路上搜尋，刪除掉 Other Linker Flag 的 -all_load 就可以解決靜態庫沖突的問題，
但是這樣做的話，會使一些外部的靜態庫，使用objc擴展函數(catagory)的方法失效。例如BaiMapApi
如果是有些庫使用到了擴展函數(catagory)可以分別對這個庫進行載入
使用：-force_load
-force_load BaiMapApi/libs/Release-iphoneos/libmapapi.a

(BaiMapApi是添加到當前目錄下的)
或
-force_load $(BUILT_PRODUCTS_DIR)/libxxx.a

(這里是直接添加靜態庫項目源碼的做法)
使用-force_load分別進行載入還是蠻方便的，如果有些函數加入了main函數使用all_load就相當麻煩了。
以上可以解決TencentOpenAPI.framework與ZbarSDK的沖突
如果兩個靜態庫沖突的結構是相同的，可以考慮將兩個靜態庫拆分出來進行合並。
查看文件的架構有哪些

$ lipo -info libzbar.a
Architectures in the fat file: libzbar.a are: armv7 (cputype (12) cpusubtype (11)) i386
將armv7解壓出來
lipo libzbar.a -thin armv7 -output libzbar-armv7.a

新建立一個文件夾出來存放解壓的(.o)文件

$ mkdir armv7
$ cd armv7
將靜態庫中的文件解壓
$ ar -x ../libzbar-armv7.a
然後將另一個靜態庫根據以上的步驟做一遍，然後觀察連個解壓的靜態庫中，有那些是一樣的就合並在一起，不過注意的是兩個靜態庫沖突的(.o)文件必須一致，否則也會出現錯誤。
合並完後進行打包了
$ libtool -static -o ../libnew-armv7.a *.o
如果像在虛擬機也使用，進行相同的步驟後，將i386的架構合並再一起就可以了。
合並靜態庫
$ lipo -create -output lib.a libnew-armv76.a libi386.a
plicate symbol是一種常見的鏈接錯誤，不像編譯錯誤那樣可以直接定位到問題的所在。但是經過一段時間的總結，發現這種錯誤總是有一些規律可以找的。

例如，我們有如下的最簡單的兩個類代碼：
// ClassA.h
#import <Foundation/Foundation.h>
@interface ClassA : NSObject
@end
// ClassA.m
#import "ClassA.h"
@implementation ClassA
@end
// ClassB.h
#import <Foundation/Foundation.h>
@interface ClassB : NSObject
@end
// ClassB.m
#import "ClassB.h」
@implementation ClassB
@end
編譯後出現的錯誤信息如下：
plicate symbol _OBJC_METACLASS_$_ClassA in:

/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o

/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.o
plicate
symbol _OBJC_CLASS_$_ClassA in:
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o

/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.old:
2
plicate symbols for architecture i386clang:
error: linker command failed with exit code 1 (use -v to see invocation)
從上面出現問題的地方，我們應該能推測出是ClassA這個類出了問題。如果這個類是我們自己寫的，就容易辦一些。
可以考慮以下原因：
1.引入頭文件時，由於疏忽，誤引入.m文件。這種一般仔細檢查一下出現問題的類的源文件就能發現。
例：ClassB.m 文件修改成下面這樣
#import "ClassB.h>"
#import "ClassA.m」 // 這句話有問題
@implementation ClassB
@end
2.同一個類，實現兩次，即有兩個@implementation 。這種一般會有一個警告，也比較容易發現。
例：ClassB.m文件修改成下面這樣：
// ClassB.m
#import "ClassB.h」
@implementation ClassB
@end
@implementation ClassA
@end
3.工程文件，同一個類文件被引入了兩次，引起這種錯誤的原因大概有兩種：一是多人協作開發時，導致project文件合並沖突；二是同名文件不在同一目錄下，添加到工程時造成重復添加。 這種一般在文件視圖，用名字過濾器檢查一下就發現了。
4.
Targets的Build Phase設置項里，查看Complie
Sources這一項，看看出現問題的類是不是有重復的，用文件名過濾也比較容易發現。這種問題一般也是多人協作開發時，project文件沖突導致的。
發現這種問題，只要刪除就可以了。不過在我解決問題過程中，刪除其中一個文件時，重復文件會自動全部刪除，所以還需要單獨添加一下。
5.如果我們的工程中引用了第三方的庫，而恰好第三方的庫裡面有一個ClassA，也會出現這種問題。如果不能修改第三方的庫代碼，只能修改我信自己的代碼了。

㈥ Android 集成三方SDK編譯時classes.jar文件沖突

這幾天的任務是將mapbox的工程合到程序中去，但是合並過程卻出現了問題
合並方法：在app的build.gradle中添加
dependencies {
compile ('com.mapbox.mapboxsdk:mapbox-android-sdk:0.7.4@aar'){
transitive=true
}
}
但是合並後會報錯：
Error:Execution failed for task ':app:dexDebug'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/Library/java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/bin/java'' finished with non-zero exit value 2
這個錯誤是由於jar包沖突，解決方法如下：
方法一：找到沖突包，將沖突包刪除，一般沖突包為'com.android.support:appcompat-v7:22.2.0'或者'com.android.support:support-v4:22.2.0'，但是我刪除沖突包後，依然報錯，於是使用方法二
方法二：因為我的沖突包是'com.android.support:support-v4:22.2.0'，所以找到項目根目錄－build－intermediates－dex-cache－cache.xml文件，將其中跟v4有關的全部刪除，然後clean project，然後將compile改為provided如下：
dependencies {
compile 'com.vividsolutions:jts:1.13'
compile 'com.squareup.okhttp:okhttp:2.4.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.4.0'
compile 'com.nineoldandroids:library:2.4.0'
compile 'com.jakewharton:disklrucache:2.0.2'
provided 'com.android.support:support-v4:21.0.0'
}

㈦ 編譯的時候找不到 SDK庫中的頭文件怎麼辦

一，引入第三方sdk時找不到頭文件問題：
我在mac mini，Xcode6.x的環境下引入了第三方SDK，同Xcode自帶的framework同放在工程的Frameworks路徑下，想在代碼中使用第三方SDK時發現找不到，而系統的framework卻能夠找到，解決辦法：
在Build Settings里搜索Search Paths 發現裡面Library Search Paths 中沒有生成剛引進的SDK路徑，自己手動添加上去（系統自帶的framework不需要添加），將裡面Library
Search Paths 中沒有用到的地址刪除,如圖：framework5是引入的第三方：
再回頭看，是否能夠引用到了第三方的庫，如果還沒有，那麼將你第三方SDK對應的framework5放到最外層文件夾，再對應的重新定位Framework Search Paths，能夠找到了吧！
二：好了，頭文件找到了，coding。。。然後編譯運行，發現報錯「_OBJC_CLASS_$_某文件名", referenced from:xx 」；
出這個錯是因為Xcode沒能自動把「_OBJC_CLASS_$_某文件名", referenced from:xx 」中的「 某文件名 」編譯進去，又需要手動去弄了，實現的部分可以是。framwork也可以是源碼文件，解決辦法，打開Project Target－》Build Phases，將「某文件」 拖到對應的位置，（如果是源碼文件拖到Compile Sources，如果是在。framework中，則將framework拖到Lind Binary With Libraries），如圖：
再編譯，如果再報錯，
1，那麼再閱讀你所使用的第三方SDK文檔，有的引入需要依賴於系統的framework，請按照說明將Xcode自帶的framework引入即可；
2，還有一種可能，靜態庫一般有兩個，一個真機調用的，一個模擬器調用的。在真機調試時使用模擬器專用的庫或反之都會報錯，你可以將它們編譯成真機和模擬器都能使用的靜態庫，方法這里不細說。

㈧ 百度sdk和導航的sdk沖突了，怎麼辦

如果你不是很懂，那就只能使用其中之一，如果你很懂程序，將沖突的地方改過來即可

望採納

㈨ 微信支付sdk接入依賴沖突

接入錯誤。當導入微信的支付SDK時，不會發生沖突，但是因為librarysearchpaths裡面ShareSDK裡面的微信SDK在前面，這就導致覆蓋了我們導入的微信SDK，會導致出現接入依賴沖突的問題，微信是騰訊公司於2011年1月21日推出的一個為智能終端提供即時通訊服務的免費應用程序。

㈩ ios 自己封裝的sdk引入了第三方庫，怎麼防止與外界的沖突

jQuery是目前使用最廣泛的前端框架之一，有大量的第三方庫和插件基於它開發。為了避免全局命名空間污染，jQuery提供了jQuery/ajax/libs/jquery/1/ajax/libs/jquery/1/ajax/libs/jquery/1/ajax/libs/jquery/1.6.4/jquery.min.js"> <!-- jQuery and $ now point to jQuery 1.6.4 --> <script>var jquery164 = jQuery.noConflict( true );</script> <!-- jQuery now points to jQuery 1.7.0; $ now points to jQuery 1.10.2; jquery164 points to jQuery 1.6.4 --> 避免第三方庫的沖突 以上的代碼片段展示了如何解決多版本jQuery的沖突。接下來，我們嘗試解決jQuery庫和第三方庫的沖突，下面出現的代碼片段在jQuery的官方文檔中都有，有興趣的程序猿可以仔細閱讀官方文檔體會其中的區別。 直接使用No-Conflict模式 使用No-Conflict模式，其實就是對jQuery進行重命名，再調用。 <!-- 採用no-conflict模式，jquery.js在prototype.js之後被引入. --> <script src="prototype.js"></script> <script src="jquery.js"></script> <script> var $j = jQuery.noConflict(); // $j 引用了jQuery對象本身. $j(document).ready(function() { $j( "div" ).hide(); }); // $ 被重新指向prototype.js里定義的對象 // document.getElementById(). mainDiv below is a DOM element, not a jQuery object. window.onload = function() { var mainDiv = $( "main" ); } </script> 使用自執行函數封裝 使用這種方式，你可以在匿名函數內部繼續使用標準的$對象，這也是眾多jQuery插件採用的方法。需要注意的是，使用這種方法，函數內部無法再使用prototype.js定義的$對象了。 <!-- jquery.js在prototype.js之後被引入. --> <script src="prototype.js"></script> <script src="jquery.js"></script> <script> jQuery.noConflict(); (function( $ ) { // Your jQuery code here, using the $ })( jQuery ); </script> 使用標准jQuery(document).ready()函數 如果jQuery庫在其它庫之前引入，那麼jQuery內部定義的jQuery和$會被第三方庫覆蓋，這時候再使用noConflict()已經沒有什麼意義了。解決的方法很簡單，直接使用jQuery的標准調用方式。 <!-- jquery.js在prototype.js之前被引入. --> <script src="jquery.js"></script> <script src="prototype.js"></script> <script> // Use full jQuery function name to reference jQuery. jQuery( document ).ready(function() { jQuery( "div" ).hide(); }); // 或者 jQuery(function($){ // Your jQuery code here, using the $ }); // Use the $ variable as defined in prototype.js window.onload = function() { var mainDiv = $( "main" ); }; </script> 下面給大家介紹jQuery noConflict() 方法 noConflict() 方法會釋放會 $ 標識符的控制，這樣其他腳本就可以使用它了。 實例 當然，您仍然可以通過全名替代簡寫的方式來使用 jQuery： $.noConflict(); jQuery(document).ready(function(){ jQuery("button").click(function(){ jQuery("p").text("jQuery 仍在運行！"); }); }); 實例 您也可以創建自己的簡寫。noConflict() 可返回對 jQuery 的引用，您可以把它存入變數，以供稍後使用。請看這個例子： var jq = $.noConflict(); jq(document).ready(function(){ jq("button").click(function(){ jq("p").text("jQuery 仍在運行！"); }); }); 實例 如果你的 jQuery 代碼塊使用 $ 簡寫，並且您不願意改變這個快捷方式，那麼您可以把 $ 符號作為變數傳遞給 ready 方法。這樣就可以在函數內使用 $ 符號了 - 而在函數外，依舊不得不使用 "jQuery"： $.noConflict(); jQuery(document).ready(function($){ $("button").click(function(){ $("p").text("jQuery 仍在運行！"); }); });