Wu Xiaotian

Before:  After: 

Don't you see that this is an obvious mistake? There is no such commit in the [oblogmsg](https://github.com/oceanbase/oblogmsg/commits/master ): 4f9e63f635e841e457cd1d6f28d80ef2e196ebea ``` 509d86f (HEAD, origin/master, origin/HEAD, master) change __thread lmb to LogMsgBuf...

> I saw the hash. > > It is a has value in the internal commit. You can remove the submodule and clean the git cache and then get the...

rebased on the last commit and changed the commit message.

> In my opinion, I think it may cause a bug when we update a new release of logmsg and the project will not get the newest submodule because there...

这个只是纯修改代码，可以同时兼容openssl-1.0和1.1，不影响现有构建方式

不是，代码加这个补丁可以兼容不同版本。 至于编译的依赖包版本，改也可以，不改也可以，甚至不单独提供也可以（这样会自动使用当前系统的openssl库）。

@whhe @LINxiansheng 使用 `cmake -DCMAKE_BUILD_TYPE=Debug ...` 可正常编译出 `observer`；而使用`cmake -DCMAKE_BUILD_TYPE=Release ...` 编译时，在最后链接时会报错如下： ``` [100%] Linking CXX executable observer cd /home/yetist/checkout/04-loongarch/oceanbase/build/src/observer && /usr/bin/cmake -E cmake_link_script CMakeFiles/observer.dir/link.txt --verbose=1 /usr/bin/g++ -fdebug-prefix-map=/home/yetist/checkout/04-loongarch/oceanbase=. -fdiagnostics-color -O3 -DNDEBUG...

> hi, 非常感谢您的贡献，在更新构建工具链的问题上OceanBase一直持谨慎的态度，我们的研发团队认为，当前白名单工具链的方式还是需要保留（比如静态链接依赖库），一方面，我们需要保证现在已经上线投产的开源用户的稳定性，另一方面，我们现在的人力只能支持白名单工具链下产物的运维。我们也欢迎您在在不影响原有设计的基础上，扩展OS兼容表； PR 标题增加了 `WIP:`，就是希望可以在充分讨论、沟通的基础上，边测试验证边完善，尽量做到在不影响现有的静态编译方式基础上，增加动态编译、支持高版本工具链和库、支持更多的发行版等特性，将 OB 改造成通用 cmake 项目，在这个过程中产生的一些合理且共性的修改，将创建单独的 PR 发起合并。 这个目标的实现需要大家一起参与，因为涉及到代码修改、工程改造，各个发行版测试反馈等大量工作要做，当然，如果没人参与，甚至 OB 社区不赞同这种做法的话，那就没必要继续浪费时间在这个上面了。

> @yetist @xen0n 谢谢你的建议, 在这个问题上, 你们也投入了很多的时间. 这是一个很大的特性. 这是个大特性没错，对于大特性的支持，也是需要通过拆分成一个一个可构建、可验证的小补丁方式合入的，这个思路是没错的。 > 在流程上: > > 1. 一个大的feature 构思之前, 大家最好在github 上提一个discussion, 然后讨论这个feature 是不是要做, 然后怎么做. 如果要做转化为issue, 跟踪起来. 之所以创建这个 PR，是因为有些问题表现出来是个综合性问题，不是简单通过issue讨论、或者创建一个单一PR就可以解决的，**需要通过可验证的代码进行呈现并加以讨论的**（如上面说的Debug可以编译，但Release却链接出错），所以希望在有可验证的代码的基础上**加以讨论**，这是创建本 PR 的初衷。 > 2. 社区做事情, 往往讨论会比较多,...