我正在编写一个包含不同压缩算法的 C++ 库，并允许用户指定一种特定的算法，然后在用户调用 compress()/Uncompress() 时使用该算法。
问题:我正在使用的一些外部库(例如 zlib)完全是 C 语言，并且由于某种原因，链接器不会像您一样优化所有 zlib 函数和数据'预计。
示例:如果用户选择希望使用 bzip，则没有指向 zlib 的代码路径，因此不应在最终二进制文件中链接/包含任何 zlib 代码。事实上，当查看/VERBOSE 链接器输出或生成的 .map 文件时，包装 zlib 的 C++ 类甚至被链接器丢弃。然而，二进制文件中仍然包含大约 30KB 的 zlib 代码。
测试重现:一个简单的控制台应用程序，其 main 返回 0，但在 Visual Studio 项目中包含 zlib 源文件，也会添加额外的约 30KB 代码。显然根本没有调用任何 zlib 函数的代码路径，那么为什么它仍然包含在可执行文件中？ map 文件中的 Zlib 符号:
0001:00000000 _adler32 00401000 f adler32.obj
0001:00002470 __tr_stored_block 00403470 f trees.obj
0001:00002510 __tr_flush_block 00403510 f trees.obj
...
0002:00001cc0 _z_errmsg 0040bcc0 zutil.obj
0002:00002330 __dist_code 0040c330 trees.obj
0002:00002530 __length_code 0040c530 trees.obj
0002:00002720 _inflate_copyright 0040c720 inftrees.obj
0002:000039a0 _deflate_copyright 0040d9a0 deflate.obj
0002:00005a68 ??_C@_00CNPNBAHC@?$AA@ 0040fa68 gzlib.obj
0002:00005a6c ??_C@_0BF@CJFPCCEG@incompatible?5version?$AA@ 0040fa6c zutil.obj
0002:00005a84 ??_C@_0N@DFPGLBGC@buffer?5error?$AA@ 0040fa84 zutil.obj
0002:00005a94 ??_C@_0BE@OGGJBMCE@insufficient?5memory?$AA@ 0040fa94 zutil.obj
0002:00005aa8 ??_C@_0L@HAHMBNLP@data?5error?$AA@ 0040faa8 zutil.obj
0002:00005ab4 ??_C@_0N@MKKNPMJD@stream?5error?$AA@ 0040fab4 zutil.obj
0002:00005ac4 ??_C@_0L@KIJFAKBJ@file?5error?$AA@ 0040fac4 zutil.obj
0002:00005ad0 ??_C@_0L@FNAOCBOG@stream?5end?$AA@ 0040fad0 zutil.obj
0002:00005adc ??_C@_0BA@MOKMMFOD@need?5dictionary?$AA@ 0040fadc zutil.obj
...
0001:00000270 _crc32_little 00401270 f CIL library: CIL module
0001:00000530 _flush_pending 00401530 f CIL library: CIL module
0001:00000580 _longest_match 00401580 f CIL library: CIL module
0001:000006e0 _fill_window 004016e0 f CIL library: CIL module
0001:00000920 _deflate_stored 00401920 f CIL library: CIL module
0001:00000c10 _deflate_fast 00401c10 f CIL library: CIL module
0001:00001000 _deflate_slow 00402000 f CIL library: CIL module
0001:00001510 _init_block 00402510 f CIL library: CIL module
0001:00001590 _pqdownheap 00402590 f CIL library: CIL module
0001:00001670 _gen_bitlen 00402670 f CIL library: CIL module
0001:00001870 _gen_codes 00402870 f CIL library: CIL module
0001:000018f0 _build_tree 004028f0 f CIL library: CIL module
0001:00001af0 _scan_tree 00402af0 f CIL library: CIL module
0001:00001bd0 _send_tree 00402bd0 f CIL library: CIL module
0001:00002150 _build_bl_tree 00403150 f CIL library: CIL module
0001:00002220 _send_all_trees 00403220 f CIL library: CIL module
0001:00002760 _compress_block 00403760 f CIL library: CIL module
0001:00002b40 _detect_data_type 00403b40 f CIL library: CIL module
0001:00002bb0 _bi_flush 00403bb0 f CIL library: CIL module
0001:00002c30 _copy_block 00403c30 f CIL library: CIL module
请求推测/帮助:我不是链接器专家，但看来罪魁祸首是 const 数组形式的数据。例如，由于 zlib 的 deflate.c 中第 131 行定义了一个数组表，因此引入了所有 CIL 模块和一些其他函数:
local const config configuration_table[10] = {
/* good lazy nice chain */
/* 0 */ {0, 0, 0, 0, deflate_stored}, /* store only */
/* 1 */ {4, 4, 8, 4, deflate_fast}, /* max speed, no lazy matches */
/* 2 */ {4, 5, 16, 8, deflate_fast},
/* 3 */ {4, 6, 32, 32, deflate_fast},
/* 4 */ {4, 4, 16, 16, deflate_slow}, /* lazy matches */
/* 5 */ {8, 16, 32, 32, deflate_slow},
/* 6 */ {8, 16, 128, 128, deflate_slow},
/* 7 */ {8, 32, 128, 256, deflate_slow},
/* 8 */ {32, 128, 258, 1024, deflate_slow},
/* 9 */ {32, 258, 258, 4096, deflate_slow}}; /* max compression */
链接器因此可以看到对函数的引用，并将所有它们也链接起来。
有人知道这是为什么吗？如果我将 zlib 和其他相关库重建为 C++，我的库会工作得更好吗？是否存在一种解决方案可供我使用，使我的库能够成功地仅链接到所需的库，而不是拉动所有其他压缩库？
感谢任何帮助!
最佳答案
我遇到了同样的问题，我可以通过添加 /Gw 编译器开关来修复它。它将从最终的可执行文件中删除未使用的全局数据。更多信息请点击:https://blogs.msdn.microsoft.com/vcblog/2013/09/11/introducing-gw-compiler-switch/
关于c - Microsoft C/C++ 链接器优化未能丢弃未使用的代码/数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22701962/