0x00 前言

这里参考gitee内关于鸿蒙官方的相关教程，通过一些自作主张的操作，发现了一些关于官方建议的原因。特此记录，估计不久之后官方可能考虑修复，但是截止2021年12月13日时官方还是未修复的状态的。已供后来者参考

技能	熟练度
Shell	精通
Linux	熟悉
编译链	熟悉

0x10 系统环境

因为当前是关于编译的实验，市面上主要是对于harmony的介绍。但是编译方面较少。这里使用Ubuntu 20的LTS版本开始编译。

文件系统使用搭载在服务器上约500G的硬盘，内部文件系统为NTFS。初始使用ARM芯片尝试编译。

0x20 踩坑记录与填坑方案

0x21 NTFS无法实现事实上的软连接

当前遇到的第一个问题就在于NTFS无法实现完全相对于EXT的权限管理于相关的软连接使用，这导致的当前的源码包可能存在一定的关联风险。而硬盘上的数据也无法被丢弃，因此笔者选择更换一块硬盘，经过测试，完整源码拖下大概有40GB左右的空间。计算上基本的磁盘开销，基本上50GB的一个硬盘，在搭建EXT3及以上的文件系统就可以完成上述的操作。

0x22 在ARM上很难实现编译

首先，这里要求的一些环境，其实在arm上就可以做到，但是因为cross的相关限制，导致当前的ARM单板无法支持过长时间的编译开销。笔者的这次首次编译的log大概输出了50M左右的数据，4.5GHz，12核心的CPU、64GB的内存，也花了4k多秒1各半小时左右，如果是低功耗的ARM芯片可能至少要花2天左右了。但是值得肯定的是，编译时对于当前的内存占有率还是可以的，大约使用了10GB左右。这更是断了一般ARM的编译的可能性。

结论：当前ARM因为资源问题，编译鸿蒙还是比较不现实的。

0x23 Ubuntu 20LTS无法编译现在的Harmony

截止2021年12月13日，暂时Harmony还无法直接编译Harmony。原因就是Harmony暂时没有对mallinfo做弃用兼容的异常处理。这里可以送给读者一个commit的机会哦~~

如果使用Ubuntu直接编译，在mem.c的时候就会触发这个弃用异常。导致无法进行下一步的编译。修改方法就是更换旧版本的glib库，或者是选择回退到老版本的Ubuntu。

0x30 关于官方不完整的解析的补充

笔者在这里严重怀疑官方是因为支持设备较少的原因，没有在任何比较显眼的位置放上对于其他库存内支持的设备的书写，笔者尝试在更新的主站、官方网站、官方社区内部搜索查找，依然没有效果。如果这里读者有设备列表，欢迎提供一下

笔者在这里只找到了官方手册关于移植的部分介绍，以此推测当前库的其他支持设备的编译的方案。

首先，根据官方移植手册的相关介绍可知，device的文件夹内是支持设备的代码空间。这里保存当前源码库内支持的设备适配的代码。

从当前的编译可以得到，主要需要的是驱动build.sh脚本进行编译。而调查得知，当前的build.sh脚本主要是简化了build.py的操作，通过检查输入的product_name的参数走向，最后笔者怀疑两点：一点是当前的device的文件名。还有一个是ohos.build的字符键值，这方面暂时笔者没有详细了解，但是至少可以编译内部的bear的单板源码。顺便说一下，这个pi是由risc32作为编译链的，需要自行编译安装，或者下载笔者提供的链接库，库兼容的是ubuntu 18LTS+Amd64，笔者后面也会出一个关于这个的教程.

0x40总结

因为笔者手头暂时没有任何可以运行Harmony的单板，所以暂时不知道具体运行起来是怎样的具体优缺点，但是不得不说，文档这方面官方的支持就相当拉跨了，几乎找不到比较简单的方案可以让我们直接获取，反而分散在四周，更是有官方的网站的详细教程，但是主仓库内的开发教程简陋的奇葩情况，笔者只能辗转网络之中收集碎片，甚至搜素到内部的设备开发商的视频教程才解决了某些关键问题。虽然使用IDE是一件轻松的事情，但是如果只是指望着官方IDE实现完全的傻瓜式操作，没有任何详细介绍相关的步骤，更像是一个已经完全知道开发流程的开发人员向新手口述程序流程——说到哪忘到哪，但是这种人为提高的学习成本的事情……国产开源资料的路还很长