谷歌协议缓冲区。 当 protobuf 构建为交叉臂时，“make install”不会生成 so 文件

Question

When I build a protobuff for arm and then install it, I don't see *.so files in the lib/ directory, only *.a and *.la . If I build it for x86, then everything is fine.

The sequence of commands is as follows:

sudo ./configure --host=amd64 --build=arm-linux-gnueabihf --target=arm-linux-gnueabihf --enable-shared --prefix=/home/rivand/install/tmp CC=/usr/bin/arm-linux-gnueabihf-gcc CXX=/usr/bin/arm-linux-gnueabihf-g++ 
sudo make -j4
sudo make install

Protobuf: protobuf-cpp-3.14.0

OS: Ubuntu 20.04

make and GCC from apt install .

Answer 1

You are mixing up --host , --build , and --target . The --host option designates the machine type on which the artifacts you are building will run. The --build option designates the machine type on which you are performing the build, and you do not ordinarily need to specify it, because the build system can guess. In fact, that's the whole purpose of the auxilliary script config.guess , which should be included in the protobuf distribution. The --target option applies only when the thing you are building is itself a cross tool; it designates the machine type for binaries that the built tool itself works with.

Having set those correctly, you probably do not need to explicitly specify the C and C++ compilers -- configure should figure them out from the host triplet. (The appearance of the host triplet in the cross tools' names is not a coincidence.)

Additionally, it would be more semantically correct to use DESTDIR at installation time than to use a --prefix at configure time. It may make a genuine difference, too, because the specified prefix is sometimes compiled into the built binaries.

Also, as a side note, use sudo only at the install step, not the configuration and build steps. It's safer that way, and it doesn't leave root-owned debris behind in the build directory. But you don't need it even then if you're installing into a directory on which you have write privileges, as you appear to be doing in your example commands.

Thus:

./configure --host=arm-linux-gnueabihf --enable-shared
make -j4
make install DESTDIR=/home/rivand/install/tmp

You will probably get some warnings from libtool at the installation step, recommending additional libtool commands to run when you eventually put the results in place in their true installation location. It is usually safe to ignore those on Linux.

I'm not entirely confident that this will get you shared libraries, because that's in part a function of the project you're building, and in part also a function of the capabilities of your cross toolchain. But it will get you properly built tools, and it has a good chance of producing the wanted shared libraries.