编译集成到ndk后，不能正常编译某些cpp文件。

[androiddeveloper-ops]

clang/clang++ 15.0编译hikari-llvm 16.0集成到ndk-r25c后，编译到某个cpp文件时好像还是会出现PassBuilder那个问题，我不清楚是啥问题。有的cpp文件可以编译通过，但是唯独将类定义在命名空间中cpp文件编译不能通过。

使用官方的llvm-project16.0 编译后集成到ndk-r25c，正常编译没有问题。

测试编译android native工程均关闭了混淆参数编译的。

集成方法参考: ollvm

[61bcdefg]

ndk-r25c对应的llvm版本不是16

[androiddeveloper-ops]

我知道是llvm版本是14，但是我也试过hikari 15.0的集成进去也是一样的不能编译特定cpp文件。

[androiddeveloper-ops]

我觉得llvm 版本相差1没什么太大影响，因为我以前编译使用过ollvm，版本也并不完全对应。

[61bcdefg]

正常编译没有问题。

测试编译android native工程均关闭了混淆参数编译的。

这是说什么混淆都没开就会报错吗

[androiddeveloper-ops]

对啊，不开启任何混淆参数，我使用官方的llvm-project 16.0编译集成后编译arm64和armeabi-v7a没有问题。
但是hikari的编译到特定cpp文件会出错。

[61bcdefg]

我知道是llvm版本是14，但是我也试过hikari 15.0的集成进去也是一样的不能编译特定cpp文件。

最好还是移植到对应的llvm再测试下，llvm14的移植方法可以参照llvm-swift-5.7的branch，翻commit记录，然后自己patch下ndk r25c的那个llvm

[Naville]

我觉得llvm 版本相差1没什么太大影响，因为我以前编译使用过ollvm，版本也并不完全对应。

你是对的, 要保持下去哦

[androiddeveloper-ops]

这个也不是说我自信说出这个话，我确实没有llvm 开发的任何经验，我也没做过llvm 开发，但我问过lsposed的一个开发人员，他使用的是hikari-llvm 16.0编译的集成到ndk-r25c，而且我测试官方llvm-project16.0编译后集成到ndk编译cpp也没有问题，
之前用gcc12.0编译hikari也出现类似问题，得出这个结论也并不是随心所欲，随口就脱口而出。

[Naville]

但我问过lsposed的一个开发人员，他使用的是hikari-llvm 16.0编译的集成到ndk-r25

Sure, LSPosed的开发经验 = 编译器开发经验

友好建议, 别这么玩。 你遇到的问题大概率是原版Hikari糟糕代码质量的问题, 他们这种Hack这么干只是看似没问题。
怎么干就随你了, 老实说我一点也不关心

[androiddeveloper-ops]

这里还是多谢大佬的指导，我会遵照这种规则，使用版本匹配的llvm去编译集成。

[yujincheng08]

🤣 @Naville 他说的那个 LSPosed 开发人员就是我。我集成倒是成功的，问题虽然不少但是都不是 ndk 集成问题，不开混淆还是可以当普通 NDK 用的。

[Naville]

🤣 @Naville 他说的那个 LSPosed 开发人员就是我。我集成倒是成功的，问题虽然不少但是都不是 ndk 集成问题。

所以说, 不要这么玩。 已知这么玩已经有海量的踩坑案例了, 比如说:

• 系统静态库使用的LLVM版本和16之间有ABI差异
• Bitcode格式不兼容
• 某条指令/Intrinsic的语义变化
• etc etc

不过LSPosed这种hobbist项目可能不是特别在乎

[yujincheng08]

其实直接换问题也不是很大，谷歌自己也这么玩。NDK 本身 master 都已经到 llvm 17 dev 了。我维护的 Magisk 倒是集成了 rust 改的 llvm-16。

[Naville]

master

所以啊, 正式出的版本肯定还是全局锁死在一个版本上的。 Rust也是类似的机制, 锁死在某个特定的LLVM commit上。

归根结底: 对于任何严肃的项目不应该这么玩, 图一乐则无所谓

[pomelohan]

经过测试 Revert 540be834 后就可以在 r25c 上正常使用了，但仍然不建议这样做。

[61bcdefg]

经过测试 Revert 540be834 后就可以在 r25c 上正常使用了，但仍然不建议这样做。

试试 61bcdefg/Hikari-LLVM15-Core@083025a 之后还会不会有问题

[pomelohan]

Sad news :(

问题仍然存在，这是日志：

值得一提的是，61bcdefg/Hikari-LLVM15-Core@8b8b5d4 不能在 ndk-r25c LLVM 14.0.7 上编译通过，故 revert，其他无任何修改。

[61bcdefg]

问题仍然存在，这是日志：

大概是什么样的cpp会报这个错，能提供例子吗

[androiddeveloper-ops]

我编译时，是将类定义在命名空间中cpp文件编译不能通过，类似java里面实体类的那种。

[androiddeveloper-ops]

我做个demo出来吧。

[Naville]

-S -emit-llvm私发给他就可以reproduce了, 不想泄密可以套一下bug point

[pomelohan]

问题仍然存在，这是日志：

大概是什么样的cpp会报这个错，能提供例子吗

很抱歉给 author 增加麻烦了，经过刚才再次测试，61bcdefg/Hikari-LLVM15-Core@083025a 已经没有问题。

刚才之所以出现问题是因为我测试用的实例代码是依托答辩，写的乱七八糟，刚才的情况是这样的：

static void xxx_Main_Sub();
void (*xx_Main_Func)() = xx_Main_Sub;

static inline void xx_Main_Sub() __attribute((__annotate__(("fla bcf_junkasm bcf_createfunc bcf_onlyjunkasm bcf sub sub_prob=100 split indibr"))))
{
……省略代码内容
}

已经去锤写这段代码的答辩哥们了。
给各位大佬添麻烦了，再次抱歉。

[Naville]

没怎么关注这个fork的代码, 但是LLVM自己有Anno2Meta了, 这里的实现有啥区别吗 @61bcdefg

EDIT: 虽然private版本的anno也是自己实现的

[61bcdefg]

没怎么关注这个fork的代码, 但是LLVM自己有Anno2Meta了, 这里的实现有啥区别吗 @61bcdefg

这个是把metadata添加到函数，不是添加到每条指令

[Naville]

确实觉得这套实现怪怪的, 提几个改进意见:

• StringRef 里我记得有atoi()实现, 不需要atoi
• convert完最好清理掉原来的那个GV里的anno
• 建议2md时用自己的MDID, 这样一次parse后面可以直接复用parse结果

[androiddeveloper-ops]

我刚刚试了一下，把这个cpp单独拿出来编译没问题，然后我刚刚是集成的hikari-llvm15.0的进去ndk-r25，再把hikari-llvm 16.0集成进去，可以编译通过了，完全没问题。应该是我工程里面也有一些测试用例不规范没有去掉的原因。
抱歉各位大佬，给你们带来了一下麻烦。

[BRYNHILDRINTHEDARKNESS]

我刚刚试了一下，把这个cpp单独拿出来编译没问题，然后我刚刚是集成的hikari-llvm15.0的进去ndk-r25，再把hikari-llvm 16.0集成进去，可以编译通过了，完全没问题。应该是我工程里面也有一些测试用例不规范没有去掉的原因。 抱歉各位大佬，给你们带来了一下麻烦。

你好大佬，请问你的开发环境是linux还是win？我在win尝试过将hikari-llvm 16.0集成进ndk-r25，但是失败了，编译的时候会报错