鸿蒙系统设备开发之编译原理 解耦 第三方库交叉编译 详解

已于 2024-04-01 15:32:26 修改
阅读量4.6k 收藏 38
点赞数 29
文章标签： harmonyos 华为 linux
于 2023-12-26 15:29:36 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhoubiaodi/article/details/135154803
版权

目录

前言

一、编译原理

1、编译解析

2、Clang/LLVM开源编译器工具链

二、鸿蒙clang交叉编译应用（编译解耦）

1、clang交叉编译hello.c示例

2、clang交叉编译C/C++项目Makefile示例

3、打包迁移clang编译工具和sysroot到别的服务器

三、鸿蒙第三方库交叉编译

1、编译zlib

2、编译openssl

3、编译mosquitto（mqtt）

4、编译libevent

4.1 下载源码

4.2 交叉编译

4.3 过程中出现的问题总结

5、编译libcurl

前言

        在Linux下，我们习惯了使用gcc、g++或其它交叉编译工具链，对C/C++应用程序进行编译。但是，在鸿蒙系统设备开发指导文档中，我们发现编写1个“Hello World”应用程序，是通过编辑BUILD.gn文件，与完整的鸿蒙系统全套代码一起整体编译打包的，整个流程耗时很长，耦合性太高。

        因此，本文将详细解析鸿蒙设备开发中的代码编译原理，将代码编译和鸿蒙源码编译解耦，达到Linux下编译的效果，并提供一些第三方库交叉编译的案例，例如libcurl、openssl库等

一、编译原理

1、编译解析

在Linux下将hello.c编译成可执行文件，在控制台中执行下面命令：

gcc hello.c -o hello

看似一条简单的命令，实际上编译工具隐藏了很多信息，我们可以在编译命令中多加一个`-v`, 也就是`gcc hello.c -o hello -v`, 它会把编译时使用的全部选项都打印出来：

通过打印信息可知，gcc编译工具实际上是另外一个编译工具文件，并且编译的时候后面添加了很多参数，如：编译的目标系统 'Target: x86_64-linux-gnu' 、cpu架构 '-march=x86-64'

查看一下gcc到底是什么，输入：

ls -l /usr/bin/gcc*

可知，gcc或g++实际上也是指向某个交叉编译工具链的软连接。

由此，可以想到，只要我们找到一个类似于gcc的编译工具，再在编译的时候指定一些链接参数，就可以为鸿蒙系统的编译各种应用了。

2、Clang/LLVM开源编译器工具链

        在后来的开发中，通过各种打印信息，发现鸿蒙系统下使用BUILD.gn配置文件对应用进行打包编译，使用了clang这个编译工具对代码进行编译，那么clang是什么东西呢？

        Clang/LLVM是一套开源的编译器工具链，用于开发编译器前端、后端、运行时及相关工具。Clang是LLVM项目的一部分，用以作为C、C++、Objective-C等语言的编译器前端，而LLVM则主要提供后端技术，可广泛应用于Windows、Linux、macOS、iOS、Android、ARM-Linux等平台。

        Clang设计目标是提供一个基于LLVM的高性能、易于使用且具有出色诊断（错误与警告信息）和GCC兼容性的编译器。Clang的一大特点是它的模块化设计，允许它被用在多种不同的情境中，比如作为IDE的代码分析工具。

        LLVM（Low Level Virtual Machine）是一个编译器基础设施，提供了一套完整的编译器组件。LLVM定义了一个中间表示（IR）语言，并提供了生成和优化IR的工具。IR是一个与硬件无关的指令集，允许编译器先将程序源码编译成IR，然后LLVM可以将IR优化和转换成针对不同机器目标平台的机器码。

        在使用Clang/LLVM编译器的时候 ，通过设定一些编译器的链接参数，就能将代码编译成目标平台上的代码，可也不是什么目标都支持，就比如OpenHarmony是一个新的操作系统，官方的Clang/LLVM就暂时还不支持，所以，我们不能用apt-get下载官方版Clang/LLVM来编译，必须用鸿蒙代码路径下的Clang/LLVM版本，这是华为公司为了OpenHarmony而特殊定制的Clang/LLVM版本，

二、鸿蒙clang交叉编译应用（编译解耦）

1、clang交叉编译hello.c示例

        鸿蒙代码路径下的Clang/LLVM版本，安装在OpenHarmony源码路径的prebuilts下，查看clang的版本信息：

/home/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm/bin/clang -v

        从打印信息中，可知clang安装目录和当前clang依赖的gcc版本。

        Clang在设计的时候，为了兼顾gcc使用者的使用习惯，继承了gcc绝大部分选项习惯，你几乎可以将gcc全套命令照搬过来，只是把gcc换成clang命令，再加上一些编译链参数即可，如下：

（1）设置"--target"选项，指定为"--target=arm-linux-ohos"

（2）设置"--sysroot"选项，用于指定编译器在编译某个芯片开发板过程中所使用的标准库和头文件所在的目录, 在OpenHarmony源码执行过某个开发板完整编译后的编译输出路径中找到这个目录（out/目录下）

（3）其它链接器的相关设置：

        浮点运算，比如 "-mfloat-abi=softfp”；

        cpu类型，比如 ”-mcpu=cortex-a55“ ；（也可不设）

        处理器架构，比如 ”-march=armv7-a“ ；（也可不设）

        ...

例如：为RK3568开发板的鸿蒙系统编译hello.c

/home/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm/bin/clang \
 -o hello hello.c -Wall \
--target=arm-linux-ohos \
--sysroot=/home/openharmony/out/rk3568/obj/third_party/musl \
-march=armv7-a -mfloat-abi=softfp

file指令可查看编译出来的可执行文件格式：

file hello

2、clang交叉编译C/C++项目Makefile示例

Makefile：

#################################################
#description: OpenHarmony make c/c++
#author: zyh
#date: 2023-11-17
#################################################
OHOS_TOOLCHAIN:=/home/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm
OHOS_SYSROOT_RK3568:=/home/openharmony/out/rk3568/obj/third_party/musl

CC:=$(OHOS_TOOLCHAIN)/bin/clang
CXX:=$(OHOS_TOOLCHAIN)/bin/clang++
AR:=$(OHOS_TOOLCHAIN)/bin/llvm-ar
AS:=$(OHOS_TOOLCHAIN)/bin/llvm-as
NM:=$(OHOS_TOOLCHAIN)/bin/llvm-nm
STRIP:=$(OHOS_TOOLCHAIN)/bin/llvm-strip
RANLIB:=$(OHOS_TOOLCHAIN)/bin/llvm-ranlib
LD:=$(OHOS_TOOLCHAIN)/bin/ld.lld
LDFLAGS:="--rtlib=compiler-rt -fuse-ld=lld"
#OHOS_CFLAGS_RK3568:= --target=arm-linux-ohos --sysroot=$(OHOS_SYSROOT_RK3568) -march=armv7-a -mfloat-abi=softfp -mcpu=cortex-a55 -mfpu=neon
OHOS_CFLAGS_RK3568:= --target=arm-linux-ohos --sysroot=$(OHOS_SYSROOT_RK3568) -march=armv7-a -mfloat-abi=softfp

TARGET=test_app

SRC_DIR:= . src
SRC_DIR+=

INC_DIR:= $(SRC_DIR)

SRCS:= $(foreach dir,$(SRC_DIR),$(wildcard $(dir)/*.c))
SRCS+= $(foreach dir,$(SRC_DIR),$(wildcard $(dir)/*.cpp))
INCS:= $(addprefix -I ,$(INC_DIR))

OBJS:= $(SRCS:.c=.o)
OBJS:= $(OBJS:.cpp=.o)
		
#CFLAGS:= -Wall -D_RK3568_OHOS
CFLAGS:= -Wall

LIBS:= -lpthread
#LIBS+= -L libs_ohos/

all: $(TARGET)
%.o: %.c
	$(CC) -c $< -o $@ $(INCS) $(CFLAGS) $(OHOS_CFLAGS_RK3568)

%.o: %.cpp
	$(CXX) -c $< -o $@ $(INCS) $(CFLAGS) $(OHOS_CFLAGS_RK3568)
	
$(TARGET): $(OBJS)
	$(CC) -o $@ $^ $(LIBS) $(OHOS_CFLAGS_RK3568)

clean:
	rm -f $(OBJS) $(TARGET)

3、打包迁移clang编译工具和sysroot到别的服务器

        根据上述的编译过程，我们可知，编译只需要依赖clang编译工具和sysroot文件，那么将鸿蒙源码下的clang编译工具和out目录下相关开发板的sysroot目录打包迁移到别的linux服务器上，我们照样可以编译，打包指令如下：

cd /home/openharmony
tar -zcf rk_ohos_cross.tar.gz prebuilts/clang/ohos/linux-x86_64/llvm out/rk3568/obj/third_party/musl

压缩文件放到其它linux服务器的某个目录下，解压即可：

tar -zxf rk_ohos_cross.tar.gz

三、鸿蒙第三方库交叉编译

1、编译zlib

  • 下载源码
wget https://zlib.net/current/zlib.tar.gz
tar -zxf zlib.tar.gz
cd zlib-1.3/
mkdir my_build
  • 鸿蒙系统开发编译环境下（建议使用官方docker容器），为rk3568开发板编译:
#配置环境变量：路径需根据实际修改
//OHOS_TOOLCHAIN：是clang编译工具的实际路径
//OHOS_SYSROOT：绝对路径，用于指定编译器在编译某个芯片开发板过程中所使用的标准库和头文件所在的目录, 在OpenHarmony源码执行过完整编译后的编译输出路径中找到这个目录（out/..）
export OHOS_TOOLCHAIN=/home/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm
export OHOS_SYSROOT=/home/openharmony/out/rk3568/obj/third_party/musl

export CC=${OHOS_TOOLCHAIN}/bin/clang
export CPP=${OHOS_TOOLCHAIN}/bin/clang++
export AR=${OHOS_TOOLCHAIN}/bin/llvm-ar
export AS=${OHOS_TOOLCHAIN}/bin/llvm-as
export NM=${OHOS_TOOLCHAIN}/bin/llvm-nm
export STRIP=${OHOS_TOOLCHAIN}/bin/llvm-strip
export RANLIB=${OHOS_TOOLCHAIN}/bin/llvm-ranlib
export LD=${OHOS_TOOLCHAIN}/bin/ld.lld
export LDFLAGS="--rtlib=compiler-rt -fuse-ld=lld"

export CFLAGS="--target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"

#编译安装,指定安装路径（prefix）
./configure --prefix=$(pwd)/my_build
make -j4
make install

2、编译openssl

  • 下载源码
wget  https://www.openssl.org/source/openssl-1.1.1a.tar.gz
tar -xvf openssl-1.1.1a.tar.gz 
cd openssl-1.1.1a/
mkdir my_build
  • 鸿蒙系统开发编译环境下（建议使用官方docker容器），为rk3568开发板编译:
#配置环境变量：路径需根据实际修改
//OHOS_TOOLCHAIN：是clang编译工具的实际路径
//OHOS_SYSROOT：绝对路径，用于指定编译器在编译某个芯片开发板过程中所使用的标准库和头文件所在的目录, 在OpenHarmony源码执行过完整编译后的编译输出路径中找到这个目录（out/..）
export OHOS_TOOLCHAIN=/home/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm
export OHOS_SYSROOT=/home/openharmony/out/rk3568/obj/third_party/musl

export CC=${OHOS_TOOLCHAIN}/bin/clang
export CXX=${OHOS_TOOLCHAIN}/bin/clang++
export AR=${OHOS_TOOLCHAIN}/bin/llvm-ar
export AS=${OHOS_TOOLCHAIN}/bin/llvm-as
export NM=${OHOS_TOOLCHAIN}/bin/llvm-nm
export STRIP=${OHOS_TOOLCHAIN}/bin/llvm-strip
export RANLIB=${OHOS_TOOLCHAIN}/bin/llvm-ranlib
export LD=${OHOS_TOOLCHAIN}/bin/ld.lld
export LDFLAGS="--rtlib=compiler-rt -fuse-ld=lld"

export CFLAGS="--target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"

#编译安装到指定目录（--prefix）

#./Configure linux-aarch64 --prefix=$(pwd)/my_build no-asm shared
./Configure linux-armv4 --prefix=$(pwd)/my_build no-asm shared

make clean
make -j4

make install

3、编译mosquitto（mqtt）

  • 下载源码
wget https://mosquitto.org/files/source/mosquitto-1.6.9.tar.gz
tar xzvf mosquitto-1.6.9.tar.gz
cd mosquitto-1.6.9/
mkdir my_build

修改成自己的安装路径：

vim config.mk

  • 鸿蒙系统开发编译环境下（建议使用官方docker容器），为rk3568开发板编译:
#配置环境变量：路径需根据实际修改
//OHOS_TOOLCHAIN：是clang编译工具的实际路径
//OHOS_SYSROOT：绝对路径，用于指定编译器在编译某个芯片开发板过程中所使用的标准库和头文件所在的目录, 在OpenHarmony源码执行过完整编译后的编译输出路径中找到这个目录（out/..）
export OHOS_TOOLCHAIN=/home/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm
export OHOS_SYSROOT=/home/openharmony/out/rk3568/obj/third_party/musl

export CC=${OHOS_TOOLCHAIN}/bin/clang
export CXX=${OHOS_TOOLCHAIN}/bin/clang++
export AR=${OHOS_TOOLCHAIN}/bin/llvm-ar
export AS=${OHOS_TOOLCHAIN}/bin/llvm-as
export NM=${OHOS_TOOLCHAIN}/bin/llvm-nm
export STRIP=${OHOS_TOOLCHAIN}/bin/llvm-strip
export RANLIB=${OHOS_TOOLCHAIN}/bin/llvm-ranlib
export LD=${OHOS_TOOLCHAIN}/bin/ld.lld
unset CFLAGS
unset CPPFLAGS
unset LDFLAGS

#编译安装，需指定openssl头文件和库路径
make clean
make WITH_SRV=no \
CFLAGS="--target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp -I/home/openharmony/samples/sutpc_project/openssl-1.1.1a/my_build/include" \
CPPFLAGS="--target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp -I/home/openharmony/samples/sutpc_project/openssl-1.1.1a/my_build/include" \
LDFLAGS="--target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp --rtlib=compiler-rt -fuse-ld=lld -L/home/openharmony/samples/sutpc_project/openssl-1.1.1a/my_build/lib -lssl -lcrypto"

make install

4、编译libevent

4.1 下载源码

也可手动去官网下载：https://libevent.org

wget https://github.com/libevent/libevent/releases/download/release-2.1.12-stable/libevent-2.1.12-stable.tar.gz
tar -zxf libevent-2.1.12-stable.tar.gz
cd libevent-2.1.12-stable/
mkdir my_build

4.2 交叉编译

鸿蒙系统开发编译环境下（建议使用官方docker容器），为rk3568开发板编译

如果不需要openssl，完整编译指令：

#配置环境变量：路径需根据实际修改
//OHOS_TOOLCHAIN：是clang编译工具的实际路径
//OHOS_SYSROOT：绝对路径，用于指定编译器在编译某个芯片开发板过程中所使用的标准库和头文件所在的目录, 在OpenHarmony源码执行过完整编译后的编译输出路径中找到这个目录（out/..）
export OHOS_TOOLCHAIN=/home/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm
export OHOS_SYSROOT=/home/openharmony/out/rk3568/obj/third_party/musl

export CC="${OHOS_TOOLCHAIN}/bin/clang -v"
#export CXX=${OHOS_TOOLCHAIN}/bin/clang++
#export CPP=${OHOS_TOOLCHAIN}/bin/clang++
export AR=${OHOS_TOOLCHAIN}/bin/llvm-ar
export AS=${OHOS_TOOLCHAIN}/bin/llvm-as
export NM=${OHOS_TOOLCHAIN}/bin/llvm-nm
export STRIP=${OHOS_TOOLCHAIN}/bin/llvm-strip
export RANLIB=${OHOS_TOOLCHAIN}/bin/llvm-ranlib
export LD=${OHOS_TOOLCHAIN}/bin/ld.lld
export LDFLAGS="--rtlib=compiler-rt -fuse-ld=lld"
unset CXX
unset CPP


export CFLAGS="-fPIC --target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"
export CPPFLAGS="-fPIC --target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"

//后续make编译提示找不到lc、lgcc、lgcc_s库等
//所以手动导入/usr目录下的库路径,需根据实际的开发板系统，选择arm gcc路径
export LIBRARY_PATH=/usr/lib/gcc-cross/arm-linux-gnueabi/7:/usr/arm-linux-gnueabi/lib

#编译安装到指定目录（--prefix），暂时不考虑openssl，所以选择参数--disable-openssl

./configure --host=arm-linux \
--prefix=$(pwd)/my_build \
--disable-openssl

make clean

//后续make编译提示找不到 crti.o、crtbeginS.o、 crtendS.o、crtn.o
//所以手动复制/usr目录下的这些文件到当前目录,需根据实际的开发板系统，选择arm gcc路径的文件
cp /usr/lib/gcc-cross/arm-linux-gnueabi/7/crtbeginS.o ./
cp /usr/lib/gcc-cross/arm-linux-gnueabi/7/crtendS.o ./
cp /usr/arm-linux-gnueabi/lib/crtn.o ./
cp /usr/arm-linux-gnueabi/lib/crti.o ./

make V=1 -j4
make install

如果需要openssl，完整编译指令：

#配置环境变量：路径需根据实际修改
//OHOS_TOOLCHAIN：是clang编译工具的实际路径
//OHOS_SYSROOT：绝对路径，用于指定编译器在编译某个芯片开发板过程中所使用的标准库和头文件所在的目录, 在OpenHarmony源码执行过完整编译后的编译输出路径中找到这个目录（out/..）
export OHOS_TOOLCHAIN=/home/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm
export OHOS_SYSROOT=/home/openharmony/out/rk3568/obj/third_party/musl

export CC="${OHOS_TOOLCHAIN}/bin/clang -v"
#export CXX=${OHOS_TOOLCHAIN}/bin/clang++
#export CPP=${OHOS_TOOLCHAIN}/bin/clang++
export AR=${OHOS_TOOLCHAIN}/bin/llvm-ar
export AS=${OHOS_TOOLCHAIN}/bin/llvm-as
export NM=${OHOS_TOOLCHAIN}/bin/llvm-nm
export STRIP=${OHOS_TOOLCHAIN}/bin/llvm-strip
export RANLIB=${OHOS_TOOLCHAIN}/bin/llvm-ranlib
export LD=${OHOS_TOOLCHAIN}/bin/ld.lld

//指定openssl库的路径
export LDFLAGS="--rtlib=compiler-rt -fuse-ld=lld -L/home/openharmony/samples/sutpc_project/openssl-1.1.1a/my_build/lib -lssl -lcrypto"
unset CXX
unset CPP


//指定openssl头文件路径
export CFLAGS="-I/home/openharmony/samples/sutpc_project/openssl-1.1.1a/my_build/include -fPIC --target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"
export CPPFLAGS="-I/home/openharmony/samples/sutpc_project/openssl-1.1.1a/my_build/include -fPIC --target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"

//后续make编译提示找不到lc、lgcc、lgcc_s库等
//所以手动导入/usr目录下的库路径,需根据实际的开发板系统，选择arm gcc路径
export LIBRARY_PATH=/usr/lib/gcc-cross/arm-linux-gnueabi/7:/usr/arm-linux-gnueabi/lib

#编译安装到指定目录（--prefix），暂时不考虑openssl，所以选择参数--disable-openssl

./configure --host=arm-linux \
--prefix=$(pwd)/my_build

make clean

//后续make编译提示找不到 crti.o、crtbeginS.o、 crtendS.o、crtn.o
//所以手动复制/usr目录下的这些文件到当前目录,需根据实际的开发板系统，选择arm gcc路径的文件
cp /usr/lib/gcc-cross/arm-linux-gnueabi/7/crtbeginS.o ./
cp /usr/lib/gcc-cross/arm-linux-gnueabi/7/crtendS.o ./
cp /usr/arm-linux-gnueabi/lib/crtn.o ./
cp /usr/arm-linux-gnueabi/lib/crti.o ./

make V=1 -j4
make install

4.3 过程中出现的问题总结

make编译提示找不到lc、lgcc、lgcc_s库，crti.o、crtbeginS.o、 crtendS.o、crtn.o等：

先使用clang -v查看当前clang当前依赖系统里面的哪个gcc版本（我的是版本7）：

再寻找/usr/目录下这些库的路径：

find /usr/ -name libgcc_s*
find /usr/ -name libc.so*

因为当前clang依赖的是gcc 7版本，而且我们是为arm开发板编译的，所以选择arm的gcc路径

手动导入库路径：

export LIBRARY_PATH=/usr/lib/gcc-cross/arm-linux-gnueabi/7:/usr/arm-linux-gnueabi/lib

再次执行，lib库能找到了，还剩下 crti.o、crtbeginS.o、 crtendS.o、crtn.o

那么从编译器详细信息来看，是想将当前目录下的 crti.o、crtbeginS.o、 crtendS.o、crtn.o一起编译。（编译器打印详细信息：可在clang 后面加参数 clang -v， 在make 后面加参数make V=1）

再寻找/usr/目录下这些文件的路径：

find /usr/ -name crti.o
find /usr/ -name crtbeginS.o

发现文件就在我们上面手动导入LIBRARY_PATH的gcc库路径里面，因此手动复制这些文件到当前目录即可。

最后执行make，还提示：

ld.lld: error: relocation R_ARM_REL32 cannot be used against symbol bufferevent_ops_filter; recompile with -fPIC

因此，我们只需要在CFLAGS后面加-fPIC参数就好了。

更新环境变量：

export CFLAGS="-fPIC --target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"
export CPPFLAGS="-fPIC --target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"

最后，重新执行configure更新Makefile，make clean后，再次复制crtbeginS.o等文件到当前目录下，再make就通过了。

5、编译libcurl

  • 下载源码
wget https://curl.haxx.se/download/curl-7.71.1.tar.gz
tar -zxf curl-7.71.1.tar.gz
cd curl-7.71.1
mkdir my_build
  • 鸿蒙系统开发编译环境下（建议使用官方docker容器），为rk3568开发板编译:
#配置环境变量：路径需根据实际修改
//OHOS_TOOLCHAIN：是clang编译工具的实际路径
//OHOS_SYSROOT：绝对路径，用于指定编译器在编译某个芯片开发板过程中所使用的标准库和头文件所在的目录, 在OpenHarmony源码执行过完整编译后的编译输出路径中找到这个目录（out/..）
export OHOS_TOOLCHAIN=/home/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm
export OHOS_SYSROOT=/home/openharmony/out/rk3568/obj/third_party/musl

export CC=${OHOS_TOOLCHAIN}/bin/clang
export AR=${OHOS_TOOLCHAIN}/bin/llvm-ar
export AS=${OHOS_TOOLCHAIN}/bin/llvm-as
export NM=${OHOS_TOOLCHAIN}/bin/llvm-nm
export STRIP=${OHOS_TOOLCHAIN}/bin/llvm-strip
export RANLIB=${OHOS_TOOLCHAIN}/bin/llvm-ranlib
export LD=${OHOS_TOOLCHAIN}/bin/ld.lld
export LDFLAGS="--rtlib=compiler-rt -fuse-ld=lld"
unset CPP
unset CXX

export CFLAGS="-fPIC --target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"
export CPPFLAGS="-fPIC --target=arm-linux-ohos --sysroot=${OHOS_SYSROOT} -march=armv7-a -mfloat-abi=softfp"

//后续make编译提示找不到lc、lgcc、lgcc_s库等
//所以手动导入/usr目录下的库路径,需根据实际的开发板系统，选择arm gcc路径
export LIBRARY_PATH=/usr/lib/gcc-cross/arm-linux-gnueabi/7:/usr/arm-linux-gnueabi/lib


#编译安装到指定目录（--prefix），需指定openssl头文件和库路径（--with-ssl）
./configure --host=arm-linux \
--target=arm-linux-ohos \
--prefix=$(pwd)/my_build \
--with-ssl=/home/openharmony/samples/sutpc_project/openssl-1.1.1a/my_build \
--enable-shared --enable-static

make clean

//后续make编译提示找不到 crti.o、crtbeginS.o、 crtendS.o、crtn.o
//所以手动复制/usr目录下的这些文件到当前lib/目录下,需根据实际的开发板系统，选择arm gcc路径的文件
cp /usr/lib/gcc-cross/arm-linux-gnueabi/7/crtbeginS.o lib/
cp /usr/lib/gcc-cross/arm-linux-gnueabi/7/crtendS.o lib/
cp /usr/arm-linux-gnueabi/lib/crtn.o lib/
cp /usr/arm-linux-gnueabi/lib/crti.o lib/

make -j4
make install
勤劳的搬运工zyh
关注
  • 29
    点赞
  • 踩
  • 38
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 17
    评论
v57.02 鸿蒙内核源码分析(编译过程) | 简单案例说透中间过程 | 百篇博客分析HarmonyOS源码
鸿蒙研究站 | 每天死磕一点点 | 由内核源码切入挖透OpenHarmony技术栈
05-31 2591
将 HarmonyOS | 鸿蒙 研究到底 < 国内 | 国外 > 百篇博客系列篇.本篇为: v57.xx 鸿蒙内核源码分析(编译过程篇) | 简单案例窥视GCC编译全过程 | 51 .c .h .o 一个.c源文件编译的整个过程如图. 编译过程要经过：源文件 --> 预处理 --> 编译(cc1) --> 汇编器(as) --> 链接器(ld) --> 可执行文件(PE/ELF) GCC GCC（GNU Compiler Collection，
鸿蒙next开发：make 交叉编译
最新发布
shudaoshanQAQ的博客
05-23 873
make 是一个标准的 Unix 构建工具，用于自动化编译过程
使用鸿蒙native交叉编译cmakelists.txt项目
破竹的博客
01-17 870
set OHOS_SDK_HONE=D:/Huawei/Sdk set OHOS_NATIVE_HOME=D:/Huawei/Sdk/native/3.0.0.0 set cmakelists_dir=D:/jhyPro/HarmonyCrossCompilation/test set bd=D:/jhyPro/HarmonyCrossCompilation/build_output/cm set output_dir=D:/jhyPro/HarmonyCrossCompilation/build_out
鸿蒙系统2.0的编译
weixin_41884251的博客
06-05 3059
这里写目录标题前言源码下载解压 前言 2021.6.2日华为发布鸿蒙2.0，真正意义上的鸿蒙系统，自持内存128M以上的设备，可以运行在手机平板等大型设备上。来凑凑热闹 源码下载 老地方下载 https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/get-code/%E6%BA%90%E7%A0%81%E8%8E%B7%E5%8F%96.md 下载下来的话大概有1.3G 解压 tar -zxvf code-2.0-canary.ta
鸿蒙(OpenHarmony)编译移植第三方库ffmpeg
SGuniver_22的博客
07-23 5993
本文非官方教程，纯属业余折腾 官方教程链接：https://device.harmonyos.com/cn/docs/develop/transplant/transplant-thirdparty-makefile-0000001064218672 一、文件准备 1. ffmpeg源码下载(本文用的n4.4) https://github.com/FFmpeg/FFmpeg/tags 2. 官方sysroot和llvm下载 sysroot目录: 克隆仓库并切到OpenHarmony-v2.2-Bet
嵌入式linux/鸿蒙开发板(IMX6ULL）开发（十）gcc编译器的使用
da.的博客
12-04 1602
1.HelloWorld背后没那么简单 2.GCC编译器的使用 3.makefile的使用
LookAround开源代码移动互联网客户端使用众多第三方库做客户端开发初步可以学习借鉴。.zip
07-30
《深入探索LookAround开源代码：移动互联网客户端的第三方库应用》 在移动互联网时代，客户端应用程序的开发变得日益复杂，而开源代码库的使用成为了解决这一问题的有效途径。LookAround开源代码项目就是一个典型的...
HCIA鸿蒙设备开发认证习题整理1
08-08
本资源摘要信息对应的知识点主要涉及到HarmonyOS设备开发认证的相关知识领域，涵盖了操作系统、编程语言、开发工具、设备驱动、软件开发等方面。 一、操作系统 * HarmonyOS设备开发需要使用到Linux操作系统（题目1...
各种第三方库
12-16
在软件开发过程中，第三方库是不可或缺的资源，它们极大地提升了开发效率，降低了代码复杂性。标题中的"各种第三方库"表明这是一个包含多个第三方库的集合，可能是为了方便开发者快速接入和学习。描述中提到这些库...
HarmonyOS云开发基础认证自刷题库
09-13
【 HarmonyOS 云开发基础认证自刷题库详解】 在当今的互联网技术发展潮流中，华为推出的HarmonyOS操作系统以其跨平台、分布式的特点受到了广泛关注。为了帮助开发者更好地掌握HarmonyOS的云开发技能，官方提供了...
汽车动力总成悬置系统设计与匹配软件开发，模态能量解耦原理
04-13
本文将深入探讨“汽车动力总成悬置系统设计与匹配软件开发”中的关键知识点，包括模态能量解耦原理和位移计算方法。 首先，我们要理解什么是动力总成。动力总成是指汽车中负责产生驱动力的所有部件，包括发动机、...
OpenHarmony啃论文俱乐部—盘点开源鸿蒙引用的三方开源软件[1]
weixin_58069108的博客
07-03 1591
OpenHarmony使用的第三方开源软件放置gitee仓库中，并命名为third_party+第三方开源软件名称，即开源鸿蒙使用的三方库。 OpenHarmony子系统会依赖一些三方库，例如: 1.复用开源跨平台UI框架flutter引擎提供基础的图形渲染能力。 2.libxkbcommon 键盘映射表编译器和支持库，被键盘事件依赖。（用于OpenHarmony标准系统对键盘的支持） 3.使用开源quickjs引擎，提供JS语言运行时和执行上下文，提供js的解析和jsframework的加载。 .....
华为鸿蒙编译器下载,华为方舟编译器
weixin_28818873的博客
05-31 1902
华为方舟编译器是最新上线的华为编译系统，用户可以在这里编译源代码，他功能强大，多种芯片联合尽心编译的运行和设一统一的平台，华为方舟编译器让用户不在只能选择安卓和苹果系统，华为鸿蒙系统的推出让用户有更多的选择，感兴趣的小伙伴就赶快来下载华为方舟编译器吧。华为方舟编译器软件介绍方舟编译器是为支持多种编程语言、多种芯片平台的联合编译、运行而设计的统一编程平台，包含编译器、工具链、运行时等关键部件。 方舟...
鸿蒙系统的编译
bizzareblizzard的专栏
09-17 2839
直接在网站上下载code-1.0.tar.gz，解压。 按照网站上配置好clang, gn, ninja, hc-gen等工具。 直接编译： ./build.py ipcamera_hi3518ev300 出现了ffmpeg连接错误，-lX11， -lXext等出错。 修改文件ffmpeg的配置文件disable_decoder_config.sh 在configure的时候加上--disable-xlib 然后就ok了。 ...
鸿蒙开发已解决-zlib.decompressFile报错
一键难忘的博客
01-11 555
这篇文档总结了遇到zlib.decompressFile报错的问题以及解决方法。问题的主要表现是zlib.decompressFile报错，截图显示了相关错误信息。其他用户也提到了类似问题，包括不支持的zip包编码、特殊字符引起的文件名问题等。通过分析，怀疑问题可能是由于文件名中包含一些特殊符号，导致鸿蒙系统认为不安全而解压失败。经过测试，发现压缩包中存在包含“~”字符的文件名，将其移除后问题解决。在Linux下压UTF-8的压缩包，包含中文文件名和中文目录名；
鸿蒙HarmonyOS应用开发之C/C++标准库机制概述
1
03-27 2437
OpenHarmony NDK提供业界标准库 libc标准库、 C++标准库 ，本文用于介绍C/C++标准库在OpenHarmony中的机制，开发者了解这些机制有助于在NDK开发过程中避免相关问题。
华为鸿蒙系统HarmonyOS学习之十四：方舟编译器
热门推荐
jyl_sh的专栏
04-12 1万+
华为鸿蒙系统HarmonyOS学习之十四：方舟编译器
在windows上交叉编译ARM(鸿蒙3.10)的golang可执行程序
yuanlulu的博客
05-13 1874
基础环境 手上有一个TB-RK3568x的ARM开发板,烧写的是鸿蒙3.10的系统，Linux内核是5.10的。 开发板信息： # cat /proc/version Linux version 5.10.79 (yuanll@yuanll-dev-pc) (aarch64-linux-gnu-gcc (Linaro GCC 7.5-2019.12) 7.5.0, GNU ld (Linaro_Binutils-2019.12) 2.28.2.20170706) #21 SMP Mon Apr 25 20:
java写的接口是否正确_关于java实现之测试第三方接口是否能正确连接？
09-06
### 回答1： 您可以使用Java编写测试代码来测试第三方接口是否能正确连接。以下是一个简单的示例代码： ```java import java.net.HttpURLConnection; import java.net.URL; public class TestConnection { public static void main(String[] args) { String url = "http://example.com/api"; // 修改为您要测试的接口地址 try { URL obj = new URL(url); HttpURLConnection con = (HttpURLConnection) obj.openConnection(); con.setRequestMethod("GET"); // 根据接口要求设置请求方法 int responseCode = con.getResponseCode(); System.out.println("Response Code : " + responseCode); // 如果返回码为200，则连接成功，否则连接失败 if (responseCode == HttpURLConnection.HTTP_OK) { System.out.println("Connection successful."); } else { System.out.println("Connection failed."); } } catch (Exception e) { e.printStackTrace(); System.out.println("Connection failed."); } } } ``` 您只需要将上述代码中的url变量替换为您要测试的接口地址，并根据接口要求设置请求方法即可。如果连接成功，将会输出"Connection successful."，否则将会输出"Connection failed."。 ### 回答2： Java写的接口是否正确主要取决于以下几个方面： 1. 接口定义是否准确：接口应包含所需的所有方法，并使用适当的参数和返回类型。接口的命名应具有描述性，清晰明确。 2. 接口实现是否完整：在实现接口时，需要确保实现了接口中定义的所有方法，并且方法的逻辑与功能与接口定义一致。此外，还要确保实现了接口中定义的所有变量和常量。 3. 接口是否满足项目需求：接口的功能是否与项目需求一致，是否满足对第三方接口的需求，例如能够正确连接和调用第三方接口提供的功能。在测试第三方接口连接是否正确时，可以编写测试代码进行连接和调用，通过比较期望的结果和实际结果来判断连接是否成功。 4. 异常处理是否完善：在连接和调用第三方接口时，可能会出现各种异常情况，例如网络连接错误、权限不足等。需要在代码中进行适当的异常处理，保证程序的可靠性和稳定性。 5. 接口的可扩展性和维护性：在实现接口时，需要考虑接口的可扩展性和维护性，使得接口可以方便地进行功能扩展和修改。 综上所述，要判断Java写的接口是否正确关于实现第三方接口的测试是否能够正确连接，需要综合考虑接口定义的准确性、实现的完整性、项目需求的满足性、异常处理的完善性以及接口的可扩展性和维护性。只有在这些方面都满足了要求，才能认为Java写的接口是正确的。 ### 回答3： 首先，我们需要了解接口的概念和特点。在Java中，接口是一种规范或契约，它定义了一组方法的名称、参数列表和返回类型，但没有具体的实现。接口可以用来实现多态性和解耦，并且允许不同的类通过实现接口来提供相同的行为。 在测试第三方接口是否能正确连接的情况下，我们通常通过编写一个实现接口的类来测试。这个类将实现接口中定义的方法，并在方法中进行与第三方接口的连接测试。通过测试这些方法的执行结果，我们可以判断连接是否成功。 接口的正确性通常从以下几个方面来判断： 1. 接口方法的参数和返回类型是否与第三方接口的要求相符。我们需要仔细查看第三方接口文档，确保我们的接口实现正确定义了对应的方法，并且参数和返回类型与文档中所描述的一致。 2. 接口方法的执行逻辑是否与第三方接口的要求相符。我们需要根据第三方接口的要求，编写适当的逻辑来进行连接测试。例如，我们可以调用第三方接口的方法并传入参数，然后判断返回结果是否符合预期。 3. 接口方法的异常处理是否充分。在连接测试过程中，我们需要考虑到各种可能的异常情况，并做出相应的处理。例如，如果网络连接出现问题，我们可以捕获异常并给出适当的错误提示。 总之，测试第三方接口是否能正确连接的过程中，需要编写一个实现接口的类来进行连接测试。通过测试接口方法的参数、返回类型、执行逻辑和异常处理是否正确，我们可以判断接口的实现是否正确。
评论 17
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

勤劳的搬运工zyh

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值