Linux下C/CPP开发，函数符号冲突问题

起因

测试给我提了一个BUG，我们的程序在连接HTTPS服务端后，莫名crash。
在还原测试环境后，通过gdb调试，发现crash在libcurl的curl_easy_platform这个函数里面，于是开启了漫长的debug之旅，最终发现是函数符号冲突所致。

还原函数符号冲突情景

首先准备三个模块

静态库libA.a
动态库libB.so
可执行二进制test.bin

静态库libA.a

静态库A主要导出一个函数接口TestFunc
主要代码：

extern "C" void TestFunc(std::string const& strData)
{
    std::cout<<"This is libtestA"<<std::endl;
    std::cout<<strData<<std::endl;
}

动态库libB.so

动态库B导出两个函数接口，一个TestFunc，另一个函数调用静态库A的TestFunc
主要代码：

extern "C" __attribute__((visibility("default"))) void TestFunc(std::string const& strData)
void TestFunc(std::string const& strData)
{
    std::cout<<"This is libtestB"<<std::endl;
    std::cout<<strData<<std::endl;
}
extern "C" __attribute__((visibility("default"))) void TestFunc_Ex()
{
    //写一个测试类，通过类里面Test函数调用静态库A的TestFunc函数
    TestClass _t;
    _t.Test();
}

可执行二进制test.bin

test.bin调用动态库B里面的两个函数接口
主要代码：

int main()
{
    TestFunc("hoho");
    TestFunc_Ex();

    return 0;
}

输出结果：

This is libtestB
hoho
This is libtestB
TestClass::Test

如果将静态库A导出的函数的参数修改为空，那么重新编译后，再运行test.bin，就复现了crash。

This is libtestB
hoho
This is libtestB
Segmentation fault (core dumped)

结果分析

理想中的结果应该是：

This is libtestB
hoho
This is libtestA
TestClass::Test

出现这个问题的原因是：
在Linux下，所有同名函数，都会被第一个加载的函数符号所代替，所以test.bin调用的时候，全部都走了动态库B的TestFunc函数。

结语

遇到这种函数符号冲突的问题，编译器通常不会给你任何提示。出现crash，只能通过gdb和经验来一步一步排查。
解决方法可以通过编译传参数来指定导出函数来解决，但我不建议这种方法。在大型项目中添加多余的编译参数及文件是一种很挫的做法。我还是建议在编码中注意规范，多检查、多用命名空间来约束、避免这类问题。

示例代码Demo下载地址