實(shí)驗(yàn)環(huán)境：MacOS 64位?

gcc版本

在官網(wǎng)下載Miracl密碼庫(kù)源碼，github上有Miracl的SDK源碼。

1、根據(jù)linux64描述，將mirdef.h64 mirdef.h mrcore.c等文件全部拷貝一份到一個(gè)單獨(dú)的文件目錄下，這個(gè)文件目錄將用于生成對(duì)應(yīng)的靜態(tài)庫(kù)文件。

2、在新建的文件目錄下，新建Makefile文件，用于管理所有的文件。（Makefile的應(yīng)用參考上一篇案例）

從第一個(gè)文件mrcore.c 開(kāi)始測(cè)試，Makefil文件如下

用make命令執(zhí)行Makefile文件，出現(xiàn)如下錯(cuò)誤提示

這是由于-m64不能被系統(tǒng)檢測(cè)，為此，我們先去掉參數(shù)-m64。再次編譯

出現(xiàn)非常多的錯(cuò)誤，首先指出

typedef unsigned mr_dltype mr_large;

按照定義，這本身是沒(méi)有問(wèn)題的，mr_dltype本身就是一個(gè)聲明類型，導(dǎo)致這個(gè)錯(cuò)誤的原因，肯定是沒(méi)有聲明mr_dltype。所以定義unsigned mr_dltype的別名為mr_large，是不可能的，后面還有很多關(guān)于mr_large的錯(cuò)誤。現(xiàn)在需要知道m(xù)r_dltype在哪里定義？

在mirdef.h有對(duì)mr_dltype的定義，雖然miracl.h有對(duì)mirdef.h的包含，但是依然沒(méi)有起作用。

問(wèn)題應(yīng)該出在__int64的定義上，__int64為long long for Unix/Linux。

__int64為微軟MSVC定義的數(shù)據(jù)類型，long long為C99定義的數(shù)據(jù)類型。

寫一小段程序測(cè)試

在本系統(tǒng)上，long類型和long long類型，都是8字節(jié)大小，所能夠表示的數(shù)據(jù)范圍為-9223372036854775808～+9223372036854775807

而且，在本系統(tǒng)上，long long類型是可用的。

現(xiàn)在，修改mirdef.h中關(guān)于__int64的定義

在MacOS arm64上編譯，與數(shù)據(jù)類型__int64相關(guān)，而__int64類型的原本定義是long long類型，在arm64上是支持的。

修改完成之后，再次用make編譯，是可以成功編譯的。

現(xiàn)在將其他的.c文件全部編譯到靜態(tài)庫(kù)文件中。

問(wèn)題又來(lái)了，在編譯mrmuldv.c的時(shí)候，出現(xiàn)了這樣的錯(cuò)誤提示

原因在于，gcc支持asm，但是不支持_asm，所以將mrmuldv.c對(duì)應(yīng)的定義修改

現(xiàn)在出現(xiàn)新的錯(cuò)誤

到這里出現(xiàn)錯(cuò)誤，屬于匯編部分內(nèi)容了。先不忙著去學(xué)習(xí)匯編，再次閱讀文檔發(fā)現(xiàn)，在mrmuldv.any中給出了各種環(huán)境的可能文件，例如選擇mrmuldv.g64wen j文件，將mrmuldv.g64修改為mrmuldv.c，然后編譯，將出現(xiàn)類似下面的錯(cuò)誤。

很明顯，這是由于系統(tǒng)環(huán)境所導(dǎo)致的。如果選擇mrmuldv.ccc，然后將mrmuldv.ccc修改為mrmuldv.c，再次編譯應(yīng)該不會(huì)出現(xiàn)上述問(wèn)題了。

編譯過(guò)程中，可能遇到的問(wèn)題，可以參考GitHub上的問(wèn)題解決。

https://github.com/miracl/MIRACL/issues/4

3、測(cè)試編譯好的靜態(tài)庫(kù)

根據(jù)linux64的指導(dǎo)，測(cè)試ecsgen，同樣的，利用Makefile管理項(xiàng)目。

將第二步生成的靜態(tài)庫(kù)放在我們的項(xiàng)目中，并添加上面的文件。

在linux64的指導(dǎo)里面，用的是g++編譯，gcc和g++是兩個(gè)不同版本，查看版本，發(fā)現(xiàn)兩者完全相同。

為什么用gcc編譯報(bào)錯(cuò)呢？

gcc是GNU開(kāi)發(fā)的針對(duì)c的編譯器，剛開(kāi)始只支持編譯c代碼，隨著gcc的發(fā)展愈發(fā)強(qiáng)大，后面gcc也支持編譯c++、Objective-c和java等，在編譯時(shí)需要通過(guò)設(shè)定參數(shù)指定編譯的語(yǔ)言。所以后來(lái)，gcc默認(rèn)編譯的是c代碼。把參數(shù)給用戶設(shè)置顯然沒(méi)有那么友好，于是就專門針對(duì)c++ 開(kāi)發(fā)了g++編譯器。所以gcc是一個(gè)編譯器集合，而g++是針對(duì)c++的編譯器。因此，想要使用gcc編譯c++的代碼需要加上參數(shù) -lstdc++ 指令即可。

或者用g++編譯，也是OK的。

很不幸，雖然能夠正確編譯了，但是在測(cè)試的時(shí)候，還是出現(xiàn)了下面的錯(cuò)誤

這必然是由于ecurve函數(shù)調(diào)用失敗導(dǎo)致的，而導(dǎo)致這個(gè)錯(cuò)誤的原因，就是因?yàn)闆](méi)有添加common.ecs文件，將這個(gè)文件包含進(jìn)項(xiàng)目，再次測(cè)試，就能夠得到正確結(jié)果。

最后，測(cè)試項(xiàng)目中包含的文件如下

4、Miracl庫(kù)是一個(gè)非常強(qiáng)大的密碼庫(kù)，在構(gòu)建這個(gè)項(xiàng)目的時(shí)候，最重要的是要生成SDK，這個(gè)過(guò)程就是生成靜態(tài)庫(kù)的過(guò)程，常常會(huì)遇到很多問(wèn)題。

主要問(wèn)題就是環(huán)境因素，在mrmuldv.any中給出了一系列的可能環(huán)境，根據(jù)自己的機(jī)器環(huán)境，選擇不同的環(huán)境代碼，才能夠得到自己的靜態(tài)庫(kù)。我想這也是為什么沒(méi)有給出一個(gè)固定的SDK的原因吧，畢竟每個(gè)人的應(yīng)用環(huán)境是不同的。但是，不得不說(shuō)，這個(gè)SDK的搭建，確實(shí)存在很大的挑戰(zhàn)。所以，小編用Makefile來(lái)管理所有文件，希望讀者在應(yīng)用的時(shí)候，能夠輕松掌握。

更多內(nèi)容，歡迎關(guān)注公眾號(hào)了解。