看起来你遇到了典型的跨发行版静态链接依赖库版本兼容性问题，这个undefined reference to symbol 'CERT_GetDefaultCertDB@@NSS_3.2'错误的根源在于NSS库的符号版本差异，下面我来拆解原因并给出可行的解决方案：

问题根源分析 #

你在Debian 7上静态编译libcurl时，链接的是Debian 7自带的旧版本NSS库（符号标记为@@NSS_3.2）。而Ubuntu 16.04、Debian Stretch这些较新的发行版，其NSS库版本已经更新，符号的版本标记（比如可能变成@@NSS_3.12或更高）或者符号定义本身发生了变化。当你在新发行版上尝试静态链接Debian 7编译的libcurl静态库时，系统的NSS静态库找不到旧版本的CERT_GetDefaultCertDB@@NSS_3.2符号，因此抛出未定义引用错误。

解决方案 #

1. 针对目标发行版单独编译libcurl静态库 #

这是最稳妥的方案，因为静态库的依赖完全匹配目标系统的库版本：

• 在Ubuntu 16.04、Debian Stretch分别执行以下步骤：
  1. 安装编译依赖：

     sudo apt-get update && sudo apt-get install libnss3-dev build-essential wget
     

  2. 下载对应版本的libcurl源码（建议和你在Debian7上使用的版本一致，避免API差异），解压后进入源码目录：

     wget https://curl.se/download/curl-<your-version>.tar.gz
     tar -xzf curl-<your-version>.tar.gz
     cd curl-<your-version>
     

  3. 配置编译选项，指定静态编译、NSS后端，禁用共享库：

     ./configure --enable-static --with-nss --disable-shared --prefix=/usr/local/custom-curl
     

  4. 编译并安装到指定目录：

     make -j$(nproc) && sudo make install
     

  5. 之后在目标发行版上编译你的静态库时，指定链接这个本地编译的libcurl静态库即可。

2. 构建完全自给自足的静态库（打包所有依赖） #

如果希望你的静态库能跨发行版直接使用，可以把libcurl和NSS的所有静态依赖都打包进最终的库中：

• 在编译libcurl时，确保配置阶段能找到NSS的静态库，并且编译时将NSS的所有依赖库（比如libnss3.a、libnssutil3.a、libsmime3.a、libssl3.a、libsqlite3.a等）一起链接进去。
• 在编译你的库时，链接命令中显式添加所有NSS相关的静态库，比如：

  g++ -Wall -o Sample Sample.cpp -Wl,-Bstatic -lyour-library -lcurl -lnss3 -lnssutil3 -lsmime3 -lssl3 -lsqlite3 -Wl,-Bdynamic
  

  注意链接顺序：依赖其他库的文件要放在前面，被依赖的放在后面。

3. 切换到OpenSSL作为SSL后端（简化跨发行版兼容） #

NSS的符号版本管理导致跨发行版静态链接兼容性较差，而OpenSSL在这方面表现更稳定。如果业务允许，可以替换SSL后端：

• 在编译libcurl时，改用OpenSSL：

  ./configure --enable-static --with-openssl --disable-shared --prefix=/usr/local/custom-curl-openssl
  

• 之后编译你的库时链接这个基于OpenSSL的libcurl静态库，跨发行版静态链接的问题会大幅减少。

额外注意事项 #

• 静态链接时链接顺序非常关键，一定要确保依赖链的顺序正确（比如先链接你的业务代码，再链接libcurl，最后链接SSL相关库）。
• 如果使用CMake、Makefile等构建工具，要确保静态库的查找路径优先指向你自己编译的版本，而不是系统默认库。

内容的提问来源于stack exchange，提问作者adnan kamili