在鸿蒙电脑中配置开发环境
C++
鸿蒙 PC 默认集成毕昇编译器(基于 Clang/LLVM),直接在终端执行:
clang --version
若输出版本信息(如 clang version 15.x.x 或包含 OHOS/BiSheng 标识),则环境已就绪。
若终端提示 command not found,需安装官方开发工具箱 DevBox,它内置了配置好的 Clang、LLVM 及环境变量:
- 安装方式:在鸿蒙“应用市场”搜索 DevBox 并安装。
- 生效操作:安装完成后,重启终端应用以加载环境变量。
- 验证命令:重启后再次运行
clang --version确认。
localhost ~ % clang --version
clang version 15.0.4 (/srv/workspace/llvm-release/2026_0313_llvm15_release/toolchain/llvm-project/clang 0e01a01d567b9acfce8edfdadb66a7b69f088fb0)
Target: aarch64-unknown-linux-ohos
Thread model: posix
InstalledDir: /data/service/hnp/ohos-sdk.org/ohos-sdk_26.0.0.18/ohos/native/llvm/bin
localhost ~ %
接下来可以尝试验证一下。在 CodeArts IDE 中输入以下代码:
#include <iostream>
using namespace std;
int main(){
int a, b;
cin >> a >> b;
cout << a + b << endl;
return 0;
}
在终端中输入如下命令:
#include <iostream>
using namespace std;
int main(){
int a, b;
cin >> a >> b;
cout << a + b << endl;
return 0;
}
关于编译命令的一些说明:
简单来说, -lc++ 是一个 链接器指令 ,它告诉编译器(更准确地说是链接器):“请把名为 libc++.dylib (或 .tbd) 的库文件链接到最终的可执行程序中”。
为什么加上这个参数就可以顺利编译了呢?这需要从编译的两个主要阶段来看:
- 编译阶段:从源代码到目标文件
当您运行 clang a.cpp 时,clang 首先会作为 编译器 工作。它读取您的 C++ 源代码文件(a.cpp),检查语法是否正确,然后将其翻译成计算机能直接理解的机器码,并生成一个中间文件,通常是 .o 文件。
在这个阶段,您的代码中使用了 cin、cout 等标准输入输出功能。编译器知道这些是 C++ 标准库提供的功能,所以它会在生成的 .o 文件中记录下对这些函数的“引用”或“需求”。
- 链接阶段:从目标文件到可执行程序
编译成功后,接下来是 链接 阶段。链接器的任务是将所有的 .o 文件和程序依赖的各种“库文件”打包、整理成一个最终可以运行的程序。
这时候问题出现了:
- 缺失的环节 :您的代码依赖于 C++ 标准库中的 cin 和 cout,但在默认情况下,clang 可能没有自动为您链接这个库。
- undefined symbol 错误 :因为链接器在所有的 .o 文件中都找不到 cin 和 cout 的实际定义,所以它会报错,提示这些符号是“未定义的”。
这就是为什么您会看到那些关于 std::n1::cin 和 std::n1::cout 的 undefined symbol 错误。
-lc++ 参数的作用
当您添加 -lc++ 参数后,您就是在明确地告诉链接器:“请务必把 C++ 标准库也包含进来。”
- 找到定义 :链接器会去系统指定的路径查找 libc++.dylib 这个库文件。
- 解决引用 :然后,它会打开这个库文件,找到 cin 和 cout 的真正定义,并将它们与您的 .o 文件中对它们的引用连接起来。
这样一来,所有的“拼图”都找到了对应的“图片”,链接器就能成功地创建出一个完整的、可以运行的程序,也就不会再报那些 undefined symbol 错误了。
简单总结一下:
在应用市场下载并安装“Python 安装器”。
localhost ~ % python
Python 3.12.8 (main, Dec 11 2024, 01:25:28) [Clang 15.0.4 (llvm-project 81cdec3cd117b1e6e3a9f1ebc4695d790c978463)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

2980

被折叠的 条评论
为什么被折叠?



