-D__const__= 在高版本gcc下会报错

[wwbmmm]

类似于brpc，这里fiber实现中也定义了-D__const__=

https://github.com/Tencent/flare/blob/master/flare/fiber/BUILD#L209

目前brpc遇到了高版本gcc下编译错误的问题：apache/brpc#1693

fiber这里可能也会遇到

[0x804d8000]

see #64 (comment).

后续我处理下

[0x804d8000]

应该已经修复了，感谢反馈。

[chen3feng]

不过这个解决不了别的代码里用errno导致的问题 Luo Bo ***@***.***> 于2022年5月30日周一 00:15写道：

…

Closed #71 <#71> as completed. — Reply to this email directly, view it on GitHub <#71 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPH4ST3JFXF2HOX56IZ3VDVMOJYLANCNFSM5XAA4MGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[0x804d8000]

不过这个解决不了别的代码里用errno导致的问题 Luo Bo @.***> 于2022年5月30日周一 00:15写道：
…

解决不了，但是其实应该也不涉及到这个问题。

出问题的原因是访问errno展开成了*errno_location()，然后这个errno_location()返回的地址是一个线程局部变量，只有在：

• 一个函数（不考虑LTO、inline）访问了两次errno；
• 编译器在第一次访问的时候把errno_location()返回值缓存在了寄存器里；
• 两次访问之间出现了fiber调度（导致寄存器里面缓存的tls地址失效）。

的情况下，才会出问题。

这儿有两种情况：

• 完全的第三方库代码，整个不涉及fiber：不满足上面第三点，不会出问题；
• 基于flare的业务代码：这种代码业务可控，可以直接用fiber::GetLastError()解决。

这个解决方案其实我理解不会显得突兀——我们实际上已经有了其他的fiber环境下的“替代品”，比如fiber::Mutex。这儿的fiber::GetLastError()也属于类似的设计思路，这种解决方案某种角度来说还有点显得比较整体化。

另外说句题外话，根据上面的分析能看出来，解决这个问题实际上需要在访问errno的目标上处理__const__，对于我们内部来说实际上也就是需要修改BLADE_ROOT。不过内部其实一直没加过-D__const__=，也没人报过问题，所以其实真实的影响面看起来也挺小的。

[0x804d8000]

为了方便向业务同学解释，这个思路可以简单的表述为，“不涉及fiber的逻辑（函数、类、被测单元等等）不需要考虑fiber；依赖fiber的逻辑，使用fiber相关的替代品”。

通常来说，一个系统除了rpc之外，还有大量的框架无关的子系统（比如整个检索引擎）。此时允许这些fiber无关的代码独立在flare之外进行开发、测试（即避免flare侵入这些模块），对于整套系统的模块化是非常重要的。

这种“不用fiber不考虑fiber、用的话需要按照fiber的要求编码”也有点c++的“what you don’t use, you don’t pay for”的那个味道。