我正在编写一个包含不同压缩算法的C++库,允许用户指定一个特定的库,然后在用户调用Compress()/Uncompress()时使用该库。
问题:我使用的一些外部库(如zlib)是严格C的,出于某些原因,链接器没有像您所期望的那样优化所有zlib函数和数据。
示例:如果用户选择使用bzip,则没有指向zlib的代码路径,因此在最终的二进制文件中不应该链接/包含zlib代码。事实上,包装zlib的C++类甚至在查看/VERBOSE链接器输出或生成的.map文件时被链接器丢弃。但是,二进制文件中仍然包含了大约30 in的zlib代码。
测试复制:是一个简单的控制台应用程序,其main返回0,但包含Visual项目中的zlib源文件,它还将添加额外的~30 of代码。显然根本没有调用任何zlib函数的代码路径,那么为什么它仍然包含在可执行文件中呢?地图文件中的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猜测/帮助请求:I不是链接器专家,但主要的罪魁祸首似乎是以const数组的形式出现的数据。例如,所有CIL模块和一些其他函数都是由于zlib的平减.c中在第131行中定义的单个数组表而引入的:
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++,我的库会更好吗?是否有一种解决方案可以让我的库成功地链接到所需的库,而不是拉出所有其他压缩库?
感谢你的帮助!
发布于 2018-02-17 03:24:06
我也遇到了同样的问题,我可以通过添加/Gw编译器开关来修复它。它将从最终的可执行文件中删除未使用的全局数据。更多信息可在这里获得:https://blogs.msdn.microsoft.com/vcblog/2013/09/11/introducing-gw-compiler-switch/
https://stackoverflow.com/questions/22701962
复制相似问题