【问题标题】:Can a Visual Studio produced static library, be stripped of symbols?可以剥离 Visual Studio 生成的静态库吗?
【发布时间】:2025-12-26 04:30:06
【问题描述】:

我将这个问题分为三个部分:

  1. 我想制作一个静态库并剥离它的符号。 (调试信息已经不包括在内) 类似于 linux 中的 strip 命令。能做到吗?

  2. windows env 中是否有与 linux 中的 nm 工具等效的工具?

  3. 使用 VS2008 创建静态库时。是否可以定义一个脚本来排除一些生成的 .obj 文件从构建和静态库之外?
    它可以是动态的吗?我的意思是我会定义一个编译模式在脚本中,这会导致特定的目标文件被排除在构建之外

【问题讨论】:

  • 没有符号的库和只写内存一样有用。

标签: c++ visual-studio-2008 static-libraries symbols


【解决方案1】:

在某些情况下,除了少量“导出”的公共符号之外,能够方便地去除所有符号,但实际上并不可行。

静态库只不过是 .obj 文件的集合。内部依赖还没有解决,直到链接时间才会解决。

例如,如果您的 .lib 由 foo.obj 和 bar.obj 组成,并且 foo.obj 中有对 bar.obj 中定义的函数的调用,那么该符号必须在链接时可用,即使没有在图书馆外面应该可以看到。

因此,您不能剥离符号(文件范围的静态符号可能除外)。即使是受保护或私有的类方法(在 C++ 意义上)也将存在于符号表中,因为可见性的实施是编译时问题,而不是链接时问题。

相比之下,动态库是已链接的独立二进制文件。从 foo.obj 到 bar.obj 的引用已经解决。因此,除了必须导出的符号(甚至可以用序号重命名或替换)之外,DLL 可以去除符号。

如果您的 DLL 公开了一个简单的 C API,那么您就大功告成了。但是如果你想公开一个 C++ 类,你可能最终会导出它的所有方法,甚至是受保护的和私有的(因为在外部应用程序中内联可能会导致直接调用私有方法)。

【讨论】:

  • 我对否决票很好奇。有人愿意发表评论,以便我改进答案吗?
  • 您回答中的第一句话也是我们正在努力实现的目标。到目前为止,选项似乎是 1)将所有不需要的符号声明为静态,2)将不需要的符号放在未命名的命名空间中,3)将不需要的符号重命名为一些垃圾(如果混淆是您的目标)。前两个选项应与统一构建结合使用,以确保不再需要私有跨对象符号。
【解决方案2】:

我一直在 VS2010 生成的 .obj 文件中找到某些(但不是全部)静态函数的名称。有趣的是,它们在我的 Release .obj 文件中可见,但在 Debug .obj 文件中不可见。我只是使用 cygwin 字符串来执行搜索:

$ strings myObjectFile.obj | grep myStaticFunctionName

我追踪到“整个程序优化 = 是”设置 (“/GL”)。当我将其切换为“否”时,函数名称不再出现。

更新:作为后续测试,我在 vim 中打开了“已清理”的 myObjectFile.obj,我仍然可以找到它们(使用 :set encoding=utf-8 或 :set encoding=latin1)。我不确定为什么字符串缺少匹配项。哦,好吧。

【讨论】:

    【解决方案3】:

    如果您认为不应该看到任何可见的内容,请尝试使用“static”关键字声明它。这告诉编译器它只能被当前模块访问。

    【讨论】:

    • 这只完成了一半的工作。该库仍然包含符号,但可以删除它们:在 linux 上,strip -x ...,在 Windows 上,我不知道如何 - 这就是问题!
    • 其实我只是编译了一个简单的文件,声明了两个函数,一个是静态的,一个不是,静态函数not出现在.lib文件中(用十六进制编辑器验证)。看来这可以满足 OP 的要求。
    • 我找不到从最终库中删除单个符号的方法,另一个答案中提到的 /REMOVE 选项似乎只从输出库中删除了整个 .obj 文件。
    • @Jimbo,如果你只是声明(和定义)静态函数,它不会出现在编译文件中。但是,如果您实际使用它,它会被包含在内。
    【解决方案4】:
    1. 不,您认为静态库的用户会如何链接到它而不知道他们使用的符号在哪里定义?
    2. 是的,试试DUMPBIN 实用程序。
    3. 嗯,是的。您可以使用/REMOVE:foo 运行LIB 实用程序。

    也就是说,我认为您正在做的事情要么不值得做,要么比删除库成员更简单。

    【讨论】: