剥离linux共享库

5 回答

• 2

  所以我们现在的解决方案如下：

  TEST.CPP

  #include <cmath>
  #include <vector>
  #include <typeinfo>
  
  struct private_struct
  {
      float f;
  };
  
  float private_function(float f)
  {
      return std::abs(f);
  }
  
  void other_private_function()
  {
      std::vector<private_struct> f(1);
  }
  
  extern "C" void __attribute__ ((visibility ("default"))) public_function2()
  {
      other_private_function();
  }
  
  extern "C" float __attribute__ ((visibility ("default"))) public_function1(float f)
  {
      return private_function(f);
  }
  

  exports.version

  LIBTEST 
  {
  global:
      public*;
  local:
      *;
  };
  

  用 . 编译

  g++ -shared test.cpp -o libtest.so -fvisibility=hidden -fvisibility-inlines-hidden -s -Wl,--version-script=exports.version
  

  给

  00000000 A LIBTEST
           w _Jv_RegisterClasses
           U _Unwind_Resume
           U std::__throw_bad_alloc()
           U operator delete(void*)
           U operator new(unsigned int)
           w __cxa_finalize
           w __gmon_start__
           U __gxx_personality_v0
  000005db T public_function1
  00000676 T public_function2
  

  这与我们正在寻找的相当接近 . 但有一些陷阱：

  • 我们必须确保在内部代码中不使用"exported"前缀（在这个简单的示例"public"中，但在我们的例子中显然更有用） .

  • 许多符号名称仍然在字符串表中结束，这似乎是RTTI，-fno-rtti使它们在我的简单测试中消失，但它是一个相当核的解决方案 .

  我很高兴接受任何人提出的更好的解决方案！

  回复于 2024-05-02T12:53:50+08:00
• 4

  您应使用-fvisibility-inlines-hidden扩充对默认可见性属性和-fvisibility = hidden的使用 .

  您还应该忘记尝试隐藏stdlib导出，请参阅this GCC bug了解原因 .

  此外，如果您在特定标头中包含所有公共符号，则可以将它们包装在 #pragma GCC visibility push(default) 和 #pragma GCC visibility pop 中，而不是使用属性 . 虽然如果您正在创建跨平台库，请查看Controlling Exported Symbols of Shared Libraries以获取统一Windows DLL和Linux DSO导出策略的技术 .

  回复于 2024-05-02T12:53:50+08:00
• 7

  请注意，Ulrich Drepper撰写了一篇关于Linux / Unix的writing shared libraries（所有？）方面的文章，其中涵盖了许多其他主题中对导出符号的控制 .

  这非常方便明确如何从共享库中仅导出白名单上的功能 .

  回复于 2024-05-02T12:53:50+08:00
• 6

  如果将私有部分包装在匿名命名空间中，则符号表中既不能显示 std::abs 也不能 private_function ：

  namespace{
  #include<cmath>
    float private_function(float f)
    {
      return std::abs(f);
    }
  }
  extern "C" float public_function(float f)
  {
          return private_function(f);
  }
  

  编译（g 4.3.3）：

  g++ -shared -o libtest.so test.cpp -s

  检查：

  # nm -DC libtest.so
           w _Jv_RegisterClasses
  0000200c A __bss_start
           w __cxa_finalize
           w __gmon_start__
  0000200c A _edata
  00002014 A _end
  000004a8 T _fini
  000002f4 T _init
  00000445 T public_function
  

  回复于 2024-05-02T12:53:50+08:00
• 5

  一般来说，在多个Linux和Unix系统中，答案是链接时没有答案 . 这对ld.so的工作原理来说是相当基础的 .

  这导致一些相当劳动密集的替代方案 . 例如，我们将STL重命名为_STL而不是 std 以避免与STL冲突，并且我们使用高，低和中间的命名空间来保持我们的符号远离与其他人符号的可能冲突 .

  这是一个你不会喜欢的解决方案：

  • 只使用暴露的API创建一个小的.so .

  • 让它用dlopen打开真正的实现，并与dlsym链接 .

  只要您不使用RTLD_GLOBAL，如果不是特别保密，您现在可以完全绝缘 . -Bsymbolic也可能是理想的 .

  回复于 2024-05-02T12:53:50+08:00