Windows下CMake通过鸿蒙SDK交叉编译三方库

前言

华为鸿蒙官方的文章CMake构建工程配置HarmonyOS编译工具链 中介绍了在Linux平台下如何使用CMake来配置鸿蒙的交叉编译环境，编译输出在Harmony中使用的第三方so库以及测试demo。

本文主要是在Windows下实现同样的操作。由于平台差异的原因，有些细节的配置会有不同。

CMake简介

CMake是一个跨平台的构建工具，用于管理构建过程、编译、链接和打包软件项目，它可以生成Makefile等用于不同操作系统和编译器的构建脚本。CMake的配置过程是跨平台的，因此可以在不同的操作系统上运行，例如Linux、Windows和macOS。

CMake构建过程可分为以下三个主要步骤：

  • 配置（Configuration）：配置阶段是CMake解析CMakeLists.txt文件的过程。在配置阶段，CMake会读取CMakeLists.txt文件，并执行其中的命令。CMakeLists.txt文件是CMake的核心，其定义了项目的构建规则和依赖关系。
  • 生成（Generation）：生成阶段是CMake根据配置阶段的结果，生成实际构建文件的过程。在生成阶段，CMake会将CMakeLists.txt文件中定义的构建规则和依赖关系转为构建工具可以理解的形式。
  • 构建（Build）：构建阶段是使用构建工具（如Make或DevEco Studio）根据生成的构建文件，编译源代码并链接生成目标文件的过程。在构建阶段，构建工具会读取生成的构建文件，按照其中定义的规则和依赖关系，执行实际的编译和链接操作。

cJSON源码准备

同样， 我们这里也使用开源的三方库cJSON进行编译。
源码地址在这里
可以使用git 克隆到本地，或者直接下载源码压缩包到本地，解压到本地
在这里插入图片描述

环境准备

这里我使用的是上篇博文中使用的HarmonyOS SDK V4.1.7版本进行编译，注意，SDK文件夹存放的路径名称中一定不能包含空格。我是直接存放在D盘根目录，如下：
在这里插入图片描述
然后还需要准备mingw编译器，在如果是Qt开发者，安装Qt的时候可以选择直接安装mingw工具，如果没有的话，可以自行下载安装一个：地址
在这里插入图片描述

开始编译

我自己在编译过程中遇到很多问题，踩了挺多坑的，为了方便理解，当前博文中也一步步的从头开始，将遇到的错误问题全部抛出来。

进入到cJSON源码目录，创建一个编译的目录 build，然后进入到build目录， 鼠标右键->在终端中打开：
在这里插入图片描述
或者通过cmd终端然后进入到build目录。

然后在终端中输入命令：

D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/bin/cmake.exe -DCMAKE_TOOLCHAIN_FILE=D:/HarmonyOS-4.1.7/11/native/build/cmake/ohos.toolchain.cmake -DCMAKE_C_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang.exe -DCMAKE_CXX_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang++.exe -DOHOS_ARCH=arm64-v8a ..

以下是分段展示，方便查看：

D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/bin/cmake.exe
-DCMAKE_TOOLCHAIN_FILE=D:/HarmonyOS-4.1.7/11/native/build/cmake/ohos.toolchain.cmake
-DCMAKE_C_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang.exe
-DCMAKE_CXX_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang++.exe
-DOHOS_ARCH=arm64-v8a …

说明：
我这里使用的是HarmonyOS SDK目录下的cmake，由于我没有设置环境变量，所以都是用的绝对路径。

  • -DCMAKE_TOOLCHAIN_FILE：交叉编译配置文件路径，设置为ohos工具链配置文件
  • -DCMAKE_C_COMPILER：配置鸿蒙SDK的C编译器
  • -DCMAKE_CXX_COMPILER：配置鸿蒙SDK的C++编译器
  • -DOHOS_ARCH：配置交叉编译的CPU架构，一般为arm64-v8a（编译64位的三方库）或armeabi-v7a（编译32位的三方库），本示例中设置编译为64位的cJSON库

执行命令后，报错：

PS F:\OpenHarmony\QTHarmony\Demo\cJSON-master\cJSON-master\build> D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/bin/cmake.exe -DCMAKE_TOOLCHAIN_FILE=D:/HarmonyOS-4.1.7/11/native/build/cmake/ohos.toolchain.cmake -DCMAKE_C_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang.exe -DCMAKE_CXX_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang++.exe -DOHOS_ARCH=arm64-v8a ..
-- Building for: Visual Studio 16 2019
-- The C compiler identification is MSVC 19.29.30038.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe -- broken
CMake Error at D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):The C compiler"C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe"is not able to compile a simple test program.It fails with the following output:Change Dir: F:/OpenHarmony/QTHarmony/Demo/cJSON-master/cJSON-master/build/CMakeFiles/CMakeTmpRun Build Command(s):C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe cmTC_22cc6.vcxproj /p:Configuration=Debug /p:Platform=x64 /p:VisualStudioVersion=16.0 /v:m && 用于 .NET Framework 的 Microsoft (R) 生成引擎版本 16.10.2+857e5a733版权所有(C) Microsoft Corporation。保留所有权利。用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.29.30038.1 版版权所有(C) Microsoft Corporation。保留所有权利。cl /c /W1 /WX- /diagnostics:column /O2 /D __MUSL__ /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_22cc6.dir\Debug\\" /Fd"cmTC_22cc6.dir\Debug\vc142.pdb" /external:env:EXTERNAL_INCLUDE /external:W1 /Gd /TC /errorReport:queue  -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -Wa,--noexecstack -Wformat -Werror=format-security -O0 -g -fno-limit-debug-info "F:\OpenHarmony\QTHarmony\Demo\cJSON-master\cJSON-master\build\CMakeFiles\CMakeTmp\testCCompiler.c"cl : 命令行 error D8021: 无效的数值参数“/Wa,--noexecstack” [F:\OpenHarmony\QTHarmony\Demo\cJSON-master\cJSON-master\build\CMakeFiles\CMakeTmp\cmTC_22cc6.vcxproj]CMake will not be able to correctly generate this project.
Call Stack (most recent call first):CMakeLists.txt:4 (project)
-- Configuring incomplete, errors occurred!

错误原因是由于在Windows下CMake默认在Windows上选择Visual Studio生成器，而非鸿蒙NDK所需的Ninja或MinGW生成器，并且-Wa,–noexecstack是Clang/Linux平台的参数，MSVC无法识别。

指定MinGW Makefiles作为生成器

所以需要在cmake命令中强制使用鸿蒙工具链的生成器，在这里我们先使用mingw作为生成器。

修改cmake命令，如下：

D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/bin/cmake.exe -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE=D:/HarmonyOS-4.1.7/11/native/build/cmake/ohos.toolchain.cmake -DCMAKE_C_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang.exe -DCMAKE_CXX_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang++.exe -DCMAKE_MAKE_PROGRAM=D:/Qt/Tools/mingw810_64/bin/mingw32-make.exe -DOHOS_ARCH=arm64-v8a ..

分段展示如下：

D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/bin/cmake.exe -G “MinGW Makefiles”
-DCMAKE_TOOLCHAIN_FILE=D:/HarmonyOS-4.1.7/11/native/build/cmake/ohos.toolchain.cmake
-DCMAKE_C_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang.exe
-DCMAKE_CXX_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang++.exe
-DCMAKE_MAKE_PROGRAM=D:/Qt/Tools/mingw810_64/bin/mingw32-make.exe
-DOHOS_ARCH=arm64-v8a …

以上cmake命令中添加了 -G "MinGW Makefiles" ，显式指定了mingw作为生成器，并且设置-DCMAKE_MAKE_PROGRAM 指定了mingw编译器的路径。

清理build目录下上一次失败运行生成缓存文件，然后再次运行：

这时候就顺利执行成功了：
在这里插入图片描述
然后再执行编译命令，编译Release版本：

cmake --build . --config Release

可以编译成功了：
在这里插入图片描述
在build目录就可以看到编译生成的so文件了：
在这里插入图片描述

至此，本文的目标 编译任务已经完成。

前面提到，还可以指定Ninja作为生成器，并且跟mingw有差异，那接下来感兴趣的可以继续一起来看看使用Ninja会遇到的问题。

使用Ninja作为生成器

接下来我们使用Ninja作为生成器，修改cmake命令如下：

D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/bin/cmake.exe -G "Ninja" -DCMAKE_TOOLCHAIN_FILE=D:/HarmonyOS-4.1.7/11/native/build/cmake/ohos.toolchain.cmake -DCMAKE_C_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang.exe -DCMAKE_CXX_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang++.exe -DCMAKE_MAKE_PROGRAM=D:/Qt/Tools/Ninja/ninja.exe -DOHOS_ARCH=arm64-v8a ..

分段展示如下 方便查看：

D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/bin/cmake.exe -G “Ninja”
-DCMAKE_TOOLCHAIN_FILE=D:/HarmonyOS-4.1.7/11/native/build/cmake/ohos.toolchain.cmake
-DCMAKE_C_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang.exe
-DCMAKE_CXX_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang++.exe
-DCMAKE_MAKE_PROGRAM=D:/Qt/Tools/Ninja/ninja.exe
-DOHOS_ARCH=arm64-v8a …

说明：
以上命令中显式指定了 -G “Ninja”，并且通过 -DCMAKE_MAKE_PROGRAM指定了ninja.exe的安装路径。

执行命令后又报错，信息如下：

-- Performing Test FLAG_SUPPORTED_fvisibilityhidden
-- Performing Test FLAG_SUPPORTED_fvisibilityhidden - Success
-- Configuring done
CMake Error at CMakeLists.txt:130 (add_library):The install of the cjson target requires changing an RPATH from the buildtree, but this is not supported with the Ninja generator unless on anELF-based platform.  The CMAKE_BUILD_WITH_INSTALL_RPATH variable may be setto avoid this relinking step.CMake Error at CMakeLists.txt:130 (add_library):The install of the cjson target requires changing an RPATH from the buildtree, but this is not supported with the Ninja generator unless on anELF-based platform.  The CMAKE_BUILD_WITH_INSTALL_RPATH variable may be setto avoid this relinking step.

问题原因：
1.RPATH 冲突​

CMake 提示 The install of the cjson target requires changing an RPATH from the build tree…，表明在安装（make install）时需要修改构建目录中的RPATH（运行时库搜索路径）。但 ​Ninja 在 Windows 上不支持修改非 Windows 原生二进制（如 Linux/鸿蒙的ELF 格式）的 RPATH​

2.​工具链配置冲突​

鸿蒙的 ohos.toolchain.cmake
可能默认启用了CMAKE_BUILD_WITH_INSTALL_RPATH（要求构建时使用安装后的 RPATH），而 Windows 上的
Ninja 无法处理此操作

解决方案是，禁用RPATH，在cmake命令中新增参数：

-DCMAKE_SKIP_RPATH=ON \
-DCMAKE_SKIP_INSTALL_RPATH=ON \
-DCMAKE_BUILD_WITH_INSTALL_RPATH=OFF

完整命令如下：

D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/bin/cmake.exe -G "Ninja" -DCMAKE_TOOLCHAIN_FILE=D:/HarmonyOS-4.1.7/11/native/build/cmake/ohos.toolchain.cmake -DCMAKE_C_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang.exe -DCMAKE_CXX_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang++.exe -DCMAKE_MAKE_PROGRAM=D:/Qt/Tools/Ninja/ninja.exe -DOHOS_ARCH=arm64-v8a -DCMAKE_SKIP_RPATH=ON -DCMAKE_SKIP_INSTALL_RPATH=ON -DCMAKE_BUILD_WITH_INSTALL_RPATH=OFF ..

分段展示如下：

D:/HarmonyOS-4.1.7/11/native/build-tools/cmake/bin/cmake.exe -G “Ninja”
-DCMAKE_TOOLCHAIN_FILE=D:/HarmonyOS-4.1.7/11/native/build/cmake/ohos.toolchain.cmake
-DCMAKE_C_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang.exe
-DCMAKE_CXX_COMPILER=D:/HarmonyOS-4.1.7/11/native/llvm/bin/clang++.exe
-DCMAKE_MAKE_PROGRAM=D:/Qt/Tools/Ninja/ninja.exe -DOHOS_ARCH=arm64-v8a
-DCMAKE_SKIP_RPATH=ON
-DCMAKE_SKIP_INSTALL_RPATH=ON
-DCMAKE_BUILD_WITH_INSTALL_RPATH=OFF …

再次执行命令，可以顺利通过，然后再执行编译命令：cmake --build . --config Release
即可完成。

技术延伸

1.​RPATH 是什么​：
ELF 格式（Linux/鸿蒙）中嵌入的动态库搜索路径，Windows 的 PE 格式不支持此机制。
​2.Ninja 的限制​：
在非 ELF 主机平台（如 Windows）编译 ELF 目标时，无法处理跨格式的 RPATH 重定向；
​3.鸿蒙的特殊性​：
目标平台为 ARM64 ELF，但主机是 Windows，工具链需交叉编译，RPATH 操作需在鸿蒙设备运行时解析（无需在构建时处理）。

以上步骤中，使用Ninja生成器，我们禁用了RPATH，那么禁用过后编译出来的库会有什么问题吗？
1. ​运行时动态库查找机制失效​

  • RPATH 的作用​：RPATH 是嵌入在 ELF 文件（鸿蒙的动态库格式）中的路径信息，用于指导动态链接器（如鸿蒙的 ld-musl.so）在运行时查找依赖库的位置。
    ​
  • 禁用后的行为​：
    编译生成的库文件（如 libcjson.so）将不再包含任何自定义的运行时库搜索路径。若该库依赖其他三方库（例如 libz.so），且这些库未放置在鸿蒙系统的默认库路径（如 /system/lib）中，则运行时会出现 ​dlopen failed: library not found​ 错误。

2. ​依赖库部署灵活性降低​
若你的库是独立的三方库（如 libcjson.so），且不依赖其他外部库，则禁用 RPATH 无影响。
若你的库依赖其他非系统库​（如自行编译的 libfoo.so），则需手动将这些依赖库部署到鸿蒙设备的系统路径，或通过环境变量指定路径，否则无法运行
。
3. ​与鸿蒙动态共享包（HSP）机制的兼容性​
鸿蒙的 HSP（动态共享包）要求库文件能通过相对路径加载依赖（例如 $ORIGIN/…/lib）
。禁用 RPATH 后，此机制失效，需依赖鸿蒙的应用内 HSP 部署规范​（如固定目录结构）解决。

为什么 MinGW 无需禁用 RPATH？​

​1.格式兼容​：MinGW 的 GCC 工具链原生支持生成和处理 ELF 格式文件，而 RPATH 是 ELF 的核心特性之一；
​2.工具链一致性​：MinGW 的链接器（ld）与 Linux 环境一致，能直接解析 RPATH 指令，无需格式转换或兼容层；
3.​交叉编译友好​：作为跨平台编译器，MinGW 在设计上已考虑非 Windows 目标（如鸿蒙）的编译需求，而 MSVC 仅聚焦 Windows 平台；

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.pswp.cn/news/912038.shtml
繁体地址，请注明出处：http://hk.pswp.cn/news/912038.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

从C学C++(6)——构造函数和析构函数

从C学C++(6)——构造函数和析构函数

从C学C(6)——构造函数和析构函数 若无特殊说明，本博客所执行的C标准均为C11. 构造函数与析构函数 构造函数定义 构造函数是特殊的成员函数，当创建类类型的新对象，系统自动会调用构造函数构造函数是为了保证对象的每个数据成员都被正确初…
阅读更多...
清理 Windows C 盘该注意什么

清理 Windows C 盘该注意什么

C 盘空间不足会严重影响系统性能。 清理 C 盘文件时，首要原则是安全。错误地删除系统文件会导致 Windows 无法启动。下面我将按照 从最安全、最推荐到需要谨慎操作的顺序，为你详细列出可以清理的文件和文件夹，并提供操作方法。 第一梯队&…
阅读更多...
Python Selenium 滚动到特定元素

Python Selenium 滚动到特定元素

文章目录 Python Selenium 滚动到特定元素⚙️ **1. 使用 scrollIntoView() 方法（最推荐）**🖱️ **2. 结合 ActionChains 移动鼠标（模拟用户行为）**🧩 **3. 使用坐标计算滚动（精确控制像素&…
阅读更多...
你写的 Express 接口 404，可能是被“动态路由”吃掉了

你写的 Express 接口 404，可能是被“动态路由”吃掉了

本文首发在我的个人博客：你写的 Express 接口 404，可能是被“动态路由”吃掉了 前情提要 最近参与公司的一个项目前端 React，后端用的 Express。目前我就做一些功能的新增或者修改。 对于 Express ，本人没有公司项目实战经验&…
阅读更多...
【Java面试】你是怎么控制缓存的更新？

【Java面试】你是怎么控制缓存的更新？

🔄 一、数据实时同步失效（强一致性） 原理：数据库变更后立即失效或更新缓存，保证数据强一致。 实现方式： Cache Aside（旁路缓存）： 读流程：读缓存 → 未命中则…
阅读更多...
react-嵌套路由 二级路由

react-嵌套路由 二级路由

什么是嵌套路由？ 在一级路由中又内嵌了其他路由，这种关系就叫做嵌套路由，嵌套至一级路由内的路由又称作二级路由 嵌套路由配置 实现步骤 配置二级路由 children嵌套 import Login from "../page/Login/index"; import Home from …
阅读更多...
【CMake基础入门教程】第八课：构建并导出可复用的 CMake 库（支持 find_package() 查找）

【CMake基础入门教程】第八课：构建并导出可复用的 CMake 库（支持 find_package() 查找）

很好！我们进入 第八课：构建并导出可复用的 CMake 库（支持 find_package() 查找）。 🎯 本课目标 你将掌握： 如何构建一个库并通过 install() 导出其配置； 如何让别人在项目中使用 find_package…
阅读更多...
Jenkins与Kubernetes深度整合实践

Jenkins与Kubernetes深度整合实践

采用的非jenkins-slave方式 jenkins配置： Jenkins添加k8s master节点的服务器信息 在Jenkins容器内部与k8s master节点设置免费登录 # docker过滤查询出运行的Jenkins服务 $ docker ps | grep jenkins# 进入Jenkins容器内部 $ docker exec -it jenkins-server /bi…
阅读更多...
GraphQL API-1

GraphQL API-1

简介 判断GraphQL方式 判断一个网站是否使用了GraphQL API，可以通过以下几种方法： 1. 检查网络请求 查看请求端点 GraphQL 通常使用单一端点，常见路径如： /graphql/api/graphql/gql/query 观察请求特征 POST 请求为主&…
阅读更多...
推荐C++题目练习网站

推荐C++题目练习网站

LeetCode LeetCode是一个全球知名的编程练习平台，提供大量C题目，涵盖数据结构、算法、系统设计等。题目难度从简单到困难，适合不同水平的学习者。平台支持在线编写代码并即时运行测试，提供详细的题目讨论区和官方解答。 Codeforc…
阅读更多...
Spring Cloud 微服务（服务注册与发现原理深度解析）

Spring Cloud 微服务（服务注册与发现原理深度解析）

📌 摘要 在微服务架构中，服务注册与发现是整个系统运行的基础核心模块。它决定了服务如何被定位、调用和管理。 本文将深入讲解 Spring Cloud 中 Eureka 的服务注册与发现机制，从底层原理到源码分析，再到实际开发中的最佳实践&a…
阅读更多...
【Linux 设备模型框架 kobject 和 kset】

【Linux 设备模型框架 kobject 和 kset】

Linux 设备模型框架 kobject 和 kset 一、Linux 设备模型概述二、kobject 与 kset 的核心概念1. kobject2. kset3. 关键数据结构 三、kobject 与 kset 的实现源码四、源码解析与使用说明1. kset 的创建与初始化2. kobject 的创建与属性3. sysfs 属性操作4. 用户空间访问示例 五…
阅读更多...
一起学前端之HTML------（1）HTML 介绍

一起学前端之HTML------（1）HTML 介绍

HTML 介绍 HTML 即超文本标记语言（HyperText Markup Language），它是构成网页的基础技术之一。HTML 借助各种标签（Tag）对网页的结构与内容加以描述。下面为你介绍其核心要点： 关键特性 标签结构&#xff…
阅读更多...
整体迁移法迁移 Docker 镜像

整体迁移法迁移 Docker 镜像

docker添加了新的镜像数据盘，数据盘迁移步骤 使用整体迁移法迁移 Docker 镜像后，可以在确认迁移成功且新数据盘正常使用后，删除旧数据目录来释放空间1。 # 停止 Docker 服务 sudo systemctl stop docker # 停止 socket 监听器 sudo systemct…
阅读更多...
智能IDE+高效数据采集，让数据获取接近0门槛

智能IDE+高效数据采集，让数据获取接近0门槛

亮数据也有了自己的官方账号，大家可以关注：https://brightdata.blog.csdn.net/ 现在正有福利，有兴趣的伙伴可以访问链接： https://www.bright.cn/products/web-scraper/?utm_sourcebrand&utm_campaignbrnd-mkt_cn_csdn_jhx…
阅读更多...
GNSS位移监测站在大坝安全中的用处

GNSS位移监测站在大坝安全中的用处

一、实时监测大坝变形 整体位移监测 GNSS（全球导航卫星系统）位移监测站能够实时、连续地获取大坝在三维空间中的位置信息，包括水平位移和垂直位移。大坝在长期运行过程中，受到水压力、温度变化、地基沉降等多种因素的影响&#x…
阅读更多...
数字图像处理（一）：从LED冬奥会、奥运会及春晚等等大屏，到手机小屏，快来挖一挖里面都有什么

数字图像处理（一）：从LED冬奥会、奥运会及春晚等等大屏，到手机小屏，快来挖一挖里面都有什么

数字图像处理（一） 一、什么是图像：图像就是多维数组图像的存储每一个格子有自己的颜色、深浅如何访问图像：1.对于RGB图像，共有R/G/B三个通道，通过代码来看。图像有单通道和多通道之分，访问时只需…
阅读更多...
关于汉语和英语哪个更先进、历史更久的争论

关于汉语和英语哪个更先进、历史更久的争论

引言：热议背后的思考​ ​ 在全球化浪潮的推动下，英语作为国际通用语言，在世界范围内广泛传播，其在国际商务、科技交流、学术研究等领域占据着重要地位。而汉语，作为世界上使用人口最多的语言之一，承载着…
阅读更多...
在不联网的情况下，从可以联网的计算机上拷贝过来的程序报错：nu1301 无法加载源，https://api.nuget.org/v3/index.json

在不联网的情况下，从可以联网的计算机上拷贝过来的程序报错：nu1301 无法加载源，https://api.nuget.org/v3/index.json

解决方法： 在联网的计算机上，找到nuget文件，拷贝到，不能联网的计算机的相应位置 设置加载这个nuget包，把nuget.org取消。 注意如果出现好多包都不能加载，可能是框架版本的问题，修改框架版本&am…
阅读更多...
TCP 状态流程及原理详解：从连接建立到性能优化

TCP 状态流程及原理详解：从连接建立到性能优化

一、TCP 协议概述与核心价值 TCP（Transmission Control Protocol，传输控制协议）是互联网协议栈中的核心协议之一，为网络通信提供可靠的、面向连接的数据传输服务。在当今复杂多变的网络环境中，深入理解 TCP 协议的状态…
阅读更多...
最新文章

Copyright @ 2022~2023