protobuf 的交叉編譯使用（C++）

大橙子瘋發表於2022-07-11
編譯C++

前言

為了提高通訊效率，可以採用 protobuf 替代 XML 和 Json 資料互動格式，protobuf 相對來說資料量小，在程式間通訊或者裝置之間通訊能夠提高通訊速率。下面介紹 protobuf 在 ARM 平臺上的使用。

簡介

官方文件給出的定義和描述：

protocol buffers 是一種語言無關、平臺無關、可擴充套件的序列化結構資料的方法，它可用於（資料）通訊協議、資料儲存等。

Protocol Buffers 是一種靈活，高效，自動化機制的結構資料序列化方法－可類比 XML，但是比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更為簡單。

你可以定義資料的結構，然後使用特殊生成的原始碼輕鬆的在各種資料流中使用各種語言進行編寫和讀取結構資料。你甚至可以更新資料結構，而不破壞由舊資料結構編譯的已部署程式。

簡單來說：

  1. 和平臺無關，和開發語言無關（支援多種語言和多個平臺）

  2. 高效：資料量小，因此更快

  3. 擴充套件性和相容性較好

使用方式

編譯安裝

1、以下僅介紹在嵌入式裝置軟體中使用，即交叉編譯開發環境，以 protobuf-3.19.3為例

$ tar -xzvf protobuf-cpp-3.19.3.tar.gz
$ cd protobuf-3.19.3/
$ ./autogen.sh

2、配置交叉編譯環境和編譯安裝後的路徑，並編譯

$ ./configure --host=arm-linux CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ --prefix=/home/protobuf/linux
$ make -j;make install

 

3、此時會在 /home/protobuf/linux 生成三個資料夾

bin：可執行檔案 protoc，可以將對應的 proto 檔案生成程式碼的工具（在 ARM 下使用，所以這個不用）

lib：對應的庫，包含靜態庫和動態庫等。還有對應裁剪版功能的lite庫

include：整合時需要包含的標頭檔案

4、重新配置編譯環境和安裝後的路徑，並編譯（Ubuntu系統）

$ ./configure --prefix=/home/protobuf/ubuntu
$ make -j;make install

 

5、此時會在 /home/protobuf/ubuntu 生成三個資料夾，和上述一樣（Ubuntu 的編譯環境），但是這個我們只需要bin檔案即可（我們使用的開發環境是 Ubuntu，所以通常都是在 Ubuntu 上執行protoc，用來生成對應的程式碼）

使用步驟

1、建立 .proto 檔案，定義資料結構，如：

// 指定版本 （預設）使用protobuf2 
syntax = "proto2"; 

// 指定名稱空間 
package ExampleNC; 

// 例1: 在 xxx.proto 檔案中定義 CExample message 

message CExample 
{
     optional string stringDesc = 1;
     optional bytes bytesVal = 2; 
}

2、通過可執行檔案 protoc 將 .proto 檔案生成對應的程式碼檔案

$ protoc -I=$SRC_DIR --cpp_out=$DST_DIR $SRC_DIR/xxx.proto

$SRC_DIR是.proto檔案所在的路徑，$DST_DIR是生成程式碼的路徑，--cpp_out 是表示生成 C++程式碼；

生成對應的 xxx.pb.h 和 xxx.pb.cc 兩個檔案，可將這兩個檔案放入需要整合的程式碼中（包括交叉編譯生成的標頭檔案include）

3、通過生成的類 CExample 定義變數，設定對應的值，如：

CExample *pInfo = new CExample();

pInfo->set_stringdesc("test");  // 賦值
printf("info: %s\n", pInfo->DebugString().c_str());// 列印設定的值（文字格式，lite版本不支援）

int length = pInfo->ByteSize();
char *pBuf = (char *)malloc(length);

pInfo->SerializeToArray(pBuf, length);// 序列化為hex
printf_hexdump("HEX:", pBuf, length);// 列印序列化後的hex資料

CExample *pOutInfo = new CExample();

pOutInfo->ParseFromArray(pBuf, length);//反序列化
printf("OUTinfo: %s\n", pOutInfo->DebugString().c_str());// 列印設定的值（文字格式，lite版本不支援）

free(pBuf);

其中，定義新的類後，若沒有進行賦值操作的變數，序列化中則沒有該資料內容

常見問題

在程式碼執行時，出現以下錯誤

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641] File already exists in database: ais_msg.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:2021] CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size): 
terminate called after throwing an instance of 'google::protobuf::FatalException'
  what():  CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size):

網上提供的解決辦法

【轉自 https://m.newsmth.net/article/Programming/single/5862/3】
Protobuf是Google的一個開源專案，它的大部分程式碼是用C++寫的。當別的程式想要使用protobuf時，既可以採用動態連結，也可以採用靜態連結。Google內部主要是採用靜態連結為主。而在Linux的世界裡，大部分發行版都把Protobuf編譯成了動態庫。
 
最佳實踐
如果你的Project本身是一個動態庫，那麼你應該避免在它的公開介面中用到任何protobuf的符號，並且採用靜態連結到protobuf的方式。同時你應該在dllmain中呼叫google::protobuf::ShutdownProtobufLibrary()來清理protobuf使用過記憶體。
如果你的Project本身是一個靜態庫，那麼決定權不在你手裡，而且最終把你的靜態庫編譯成PE/ELF檔案的那個人手裡。但是你需要在你的build system中留出介面讓他可以告知你這個資訊。
如果你的Project本身是一個動態庫，並且你公開介面中用到了protobuf的符號，那麼你必須動態連結到protobuf。 否則當你跨DLL傳送protobuf的物件時，如果這個物件在A.DLL中建立，但是在B.DLL中被銷燬，那麼就會導致程式崩潰。因為當你採用靜態連結到Protobuf時，每個DLL內部都有一個protobuf的副本，並且protobuf內部有自己的記憶體池。跨DLL傳輸物件就會導致該物件可能在不屬於自己的記憶體池中被釋放。
 
動態連結的注意事項
首先，不推薦在Windows上這麼做。 因為protobuf本身是基於C++的，而Windows上DLL的匯出符號應該都是C風格的，不應含有任何STL、std::string這樣的東西。 如果你一定要這麼做，那麼你就會收到C4251警告。這是一個level 1的警告，屬於最高嚴重等級。
如果你決定動態連結到protobuf，並且目標平臺是Windows作業系統，那麼你應該在編譯你的project的原始碼的時候"#define PROTOBUF_USE_DLLS"。 這樣連結器才知道應該使用dllimport的方式去尋找protobuf的符號。 Linux不需要這麼做。但是Linux需要注意把code編譯成PIC的。 同時，在Windows上需要注意所有程式碼必須採用動態連結到CRT，而不能採用靜態連結。 這條適用於libprotobuf.dll自身以及它的所有使用者。
 
無論是Windows還是Linux，動態連結帶來的另一個問題是：從.proto生成的那些C/C++程式碼可能也需要被編譯成動態庫共享。因為protobuf本身有一個global的registry。每個message type都需要去那裡註冊一下，而且不能重複註冊。所以，假如你在A.DLL中定義了某些message type，那麼B.DLL就只能從A.DLL的exported的DLL interface中使用這些message type, 而不能從proto檔案中重新生成C/C++程式碼幷包含到B.DLL裡去。並且B.DLL也不能私自的去修改、擴充套件這個message type。據說換成protobuf-lite就能避免這個問題，但是Google官方並沒有對此表態。
 
另外，protobuf動態庫自身不能被unload然後reload。 這個限制讓我很意外，但是Google自己說他們在設計的時候從來沒考慮過這樣的使用場景。不過，在Linux上這其實是很常見的事情，GLIB自身都不支援unload。
 
糟糕的用例：Tensorflow
首先，tensorflow作為一個python的plugin,它必須是動態庫，不能是靜態庫。
Tensorflow選擇了靜態連結到protobuf。
Tensorflow想要支援動態載入plugin。每個plugin是一個動態庫。
plugin本身需要訪問Tensorflow的介面，而這些介面常常又含有protobuf的符號。Tensorflow會暴露(provide) libprotobuf 的部分符號。如果這個plugin需要的符號恰好在tensorflow中都能找到，那麼很好。 但事情並非總是如此， 因為Tensorflow它只有一個partial的libprotobuf，它只包含它自己所必須的那部分protobuf的code。當這個plugin想要的超出了tensorflow所能提供的範疇，寫plugin的人就會嘗試把protobuf加到link command中。這樣就會變得非常非常危險，程式隨時會崩潰。因為它會在兩個不同的protobuf副本之間傳送protobuf的物件。 所以，不要看到“unresolved external symbol”就不動腦子的把缺的庫加上，有時候這個錯誤代表的是更深層次的問題。
 
糟糕的用例： cmake
cmake 3.16做了一個火上澆油的事情：當你使用find_package(Protobuf)的時候，你需要提前知道你找到的究竟是動態庫還是靜態庫，如果是靜態庫那麼你需要設定Protobuf_USE_STATIC_LIBS成OFF，否則在Windows上鍊接會失敗。請注意： 不是cmake告訴你它找到的是什麼，而是你要主動告訴它，它找到的會是什麼。

首先說明錯誤的具體原因：因為需要通訊多個程式模組都整合了相同的 *.pb.cc 和 *.pb.h 檔案進行編譯（動態庫或者執行檔案），且在編譯時通過動態庫 libprotobuf.so 的方式進行連結。

因為這個，導致在執行時報錯，通過網上查詢得到：protobuf 本身有一個 global 的 registry。每個 message type 都需要去那裡註冊一下，而且不能重複註冊。上述的 Add 錯誤就是因為註冊失敗，原因就是因為這幾個中重複註冊了（多份 *.pb.cc 實現）。

解決方案

根據網上的解決方案，我自己也實驗了，歸納如下：

1、靜態庫編譯，使用 libprotobuf.a，即多個編譯目標通過靜態庫的方式連結，但是這種方式勢必會導致程式編譯後的目標大小增大，不太適合 ARM 容量小的裝置。如果編譯目標是動態庫，則需要在交叉編譯 protobuf 加上-fPIC。

$ ./configure --host=arm-linux --disable-shared CFLAGS="-fPIC -fvisibility=hidden" CXXFLAGS="-fPIC -fvisibility=hidden" CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ --prefix=/home/protobuf/linux
$ make -j;make install

或者改 configure 檔案再執行 configure

// 改成下面的樣子（不同版本位置不對，所以可以搜尋 ac_cv_env_CFLAGS_set）
if test "x${ac_cv_env_CFLAGS_set}" = "x"; then
 CFLAGS="-fPIC"
fi

if test "x${ac_cv_env_CXXFLAGS_set}" = "x"; then
  CXXFLAGS="-fPIC"
fi
$ ./configure --host=arm-linux --disable-shared CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ --prefix=/home/protobuf/linux
$ make -j;make install

2、使用 protobuf-lite 版本，可以通過動態庫 libprotobuf-lite.so 連結，但這個版本裁剪了很多功能，只保留了基本功能，這個需要修改 *.proto 檔案，增加 option optimize_for  選項，重新生成 *.pb.cc 和 *.pb.h 檔案，然後各模組整合編譯即可。

// 指定版本 （預設）使用protobuf2 
syntax = "proto2"; 

// 使用 lite 版本
option optimize_for = LITE_RUNTIME;

// 指定名稱空間 
package ExampleNC; 

// 例1: 在 xxx.proto 檔案中定義 CExample message 

message CExample 
{
     optional string stringDesc = 1;
     optional bytes bytesVal = 2; 
}

3、將生成的 *.pb.cc 和 *.pb.h 和 libprotobuf.a 編譯成一個新的動態庫 libprotobuf-new.so，其他模組包含 *.pb.h 檔案並通過動態庫的方式連結這個新的動態庫即可。

這種方式解決了上述問題，也保留了全部功能，但是對於後續的維護存在一定問題，如果更新 *.proto 檔案，重新生成並編譯了 libprotobuf-new.so，那麼其他使用的模組也必須都更新*.pb.h 檔案重新編譯，否則在使用中會遇到:

  1. 程式包只替換了 libprotobuf-new.so ，程式執行時可能存在踩踏資料的情況，引發系統異常
  2. 程式包只替換了其他模組的庫，並沒有替換 libprotobuf-new.so ，就會導致程式崩了

所以，在多人合作開發的程式實現資料通訊時，這種方式並不好，相容性太差，因為需要替換所有涉及的模組動態庫或者執行檔案

以上三種解決方案各有利弊，可以根據實際情況選擇

 

相關文章