企业官网建设流程全解析

简介：针对VS2005环境编译podofo 0.9.7的需求，这份资源提供了一套可直接打开的C++工程，将开源PDF读写库及其依赖项统一编译为lib静态库，适合需要在旧版Visual Studio中集成PDF解析与生成功能的开发者。资源包共1382个文件，压缩后42.38MB，其中以372个头文件、327个C源码、279个obj中间文件及102个cpp文件为主，同时附带了freetype、libjpeg、libpng、libtiff、zlib、openssl等依赖库的预编译产物，并保留了dsp/dsw/sln等经典工程文件，便于在VS2005中直接加载编译。工程中已对文档加密宏PODOFO_HAVE_OPENSSL做出开关配置，无需加密时可关闭相关依赖，避免额外连接库；两个依赖Linux的用例默认禁用，不影响常规编译使用。已有571人浏览学习，适合具备一定C++基础、希望在老版本VS下快速获得可用PDF库的开发者参考。若启用加密功能，需按说明将两个dll放入程序目录并链接对应lib，整体思路清晰，可大幅减少自行搭建依赖链的时间。

1. 为什么还在 VS2005 上编译 podofo 0.9.7：老系统的 PDF 导出缺口

某公司内部系统，跑在 Windows XP 上，MFC 界面，VS2005 编译，一用就是十几年。今年业务方要求把每张业务单据直接落成 PDF，调研了一圈发现：新库基本要求 VS2015+，老系统一动编译器，几百个源文件的坑根本填不完。剩下能选的路径里，podofo 0.9.7 是少有的几个 C++ 写的、仍保持 C++03 风格、兼容老编译器设计最彻底的开源 PDF 读写库。而把 podofo 0.9.7 编成 VS2005 能用的静态 lib，本身就是一场和老编译器、老依赖库的拉锯战。这篇笔记把依赖库版本选择、CMake 生成与补丁、三个依赖库的预编译、以及老编译器特有的报错解法全部写清楚，适合正在维护十年老系统、又必须把 PDF 能力补进去的工程师照着走一遍。

2. podofo 0.9.7 的依赖边界与 VC8 编译器上限：动手前先摸清配置策略

2.1 podofo 0.9.7 的模块结构：核心库与六个可选依赖

podofo 0.9.x 把代码拆成两层：底层 pocore 负责对象模型、xref 表、Parser、Flate 解压缩和加密相关的底层支持；上层 podofo 封装 PdfDocument、PdfPage、PdfPainter、图像与字体操作。编译完成后你会发现 build 目录里同时产出 pocore.lib 和 podofo.lib 两个静态库，这说明两层是分开链接的，后续你链接自己的程序时两个库都得给到链接器，少一个就报无法解析的外部符号。

依赖库方面，0.9.7 的 CMake 里能看到的开关包括 zlib、libpng、libjpeg、freetype、openssl、libxml2 几大类。其中 zlib 是硬依赖，所有 Flate 压缩流和跨版本结构都要用到它，几乎不可能绕开；libpng 和 libjpeg 用来把图片塞进 PDF 或者从 PDF 里抽图片，做业务单据导出时大概率会碰上 logo、印章、扫描件，所以建议保留；freetype 负责 TrueType 字体解析，属于锦上添花；openssl 管 PDF 加密与签名，很多内部系统根本不需要；libxml2 管 XMP 元数据，一般也用不上。

提示：VS2005 环境下我建议只保留 zlib + libpng + libjpeg，把 freetype、openssl、libxml2 全部关掉。每少一个依赖，就少一整套「老编译器编新代码」的未知数。开关在 CMake 阶段就能关掉，等编译到一半再发现依赖没装，返回成本很高。

2.2 VC8 编译器上限：C++03 都不完整，却偏偏够用

VS2005 的 C++ 编译器（VC8）在标准支持上的真实水平，比 C++03 还要残缺一点：没有完整的 TR1，没有 stdint.h，snprintf 家族是个摆设，连 std::shared_ptr 都是 VS2008 才进来的。这意味着 2016 年之后任何「现代 C++ 味道」的开源库，放到 VC8 面前基本都是直接卡死，你甚至连编译的第一个文件都过不去。

podofo 0.9.7 之所以还能选，是因为它在这件事上做了条件编译兜底：代码里大量用类似 PODOFO_HAVE_TR1 之类的宏做分支，遇到 VC8 这种没有 TR1 的环境，会退回自己的 fallback 实现，或者直接走 C++03 路径。换句话说，podofo 源码本身在 VS2005 下是能立住的，真正让你翻车的往往不是 podofo，而是它拽进来的依赖库——依赖库版本选新了，一堆 C99 / C++11 语法砸过来，VC8 直接投降。

还要留意 VC8 的模板解析：它实现的是老式两阶段查找，依赖模板参数的表达式经常报出让人摸不着头脑的 C2065「未声明的标识符」。你在自己的调用代码里如果写了花哨的模板技巧，编译 podofo 头文件时也可能被牵连。所以老工程调用 podofo 时尽量写朴素代码，别用 C++11 时代的奇技淫巧。

2.3 版本锁定策略：老编译器配老依赖，绝不追新

反复踩坑后我总结出这样一套版本组合，也是后面几章操作所依据的组合。核心原则只有一个：老编译器配老依赖，版本跑通就永久锁死，绝不追新。

这里解释一下为什么 libpng 是重灾区：libpng 从 1.4 往后头文件里逐步引入 C99 的类型定义，1.6 直接依赖 stdint.h，而 VS2005 的 include 目录里根本没有这个文件。你当然可以造假头文件，但很多类型冲突会接着冒出来，你是来编译 PDF 库的，不是来给 libpng 做移植的——所以直接锁 1.2.59，是最划算的决策。libjpeg 选 9b 而不是 6b，是因为 6b 虽然是老经典，但 9b 修了一批安全和 CMYK 转换问题，且两者编译成本一样，没理由用 1998 年的版本。

3. 用 CMake 生成 VS2005 工程：最小命令与工程内四个必改配置

3.1 CMake 版本选择与最小生成命令

VS2005 在 CMake 里对应的生成器名是Visual Studio 8 2005。注意两件事：第一，生成器名少一个空格、写成 "Visual Studio 8" 或 "VS8 2005" 都会直接报错；第二，高版本 CMake 已经把这个老生成器删掉了，目前最新的 CMake 早已不提供 Visual Studio 8 2005 生成器，推荐用 3.19 这个最后的稳定版本，在命令行里用它的完整路径调用，不污染系统 PATH。

假设源码解压在 D:\build\podofo-0.9.7，依赖库后续统一整理到 D:\build\deps，在源码目录下执行：

cd D:\build\podofo-0.9.7 mkdir build_vs2005 cd build_vs2005 cmake.exe -G "Visual Studio 8 2005" ^ -DCMAKE_PREFIX_PATH=D:\build\deps ^ -DCMAKE_INSTALL_PREFIX=D:\build\podofo-install ^ -DPODOFO_BUILD_SHARED=OFF ^ -DPODOFO_BUILD_LIB_ONLY=ON ^ -DPODOFO_USE_LIBJPEG=ON ^ -DPODOFO_USE_LIBPNG=ON ^ -DPODOFO_USE_ZLIB=ON ^ -DPODOFO_USE_FREETYPE=OFF ^ -DPODOFO_USE_OPENSSL=OFF ^ -DPODOFO_USE_LIBXML2=OFF ^ ..

参数说明：-G指定生成器，CMake 会据此产出 .sln 和 .vcproj 而不是 Makefile；^是 Windows 命令行续行符，在 cmd 里有效，PowerShell 里要用反引号。CMAKE_PREFIX_PATH让 FindPNG、FindJPEG、FindZLIB 去 D:\build\deps 里找依赖库的根目录，这意味着后续编译完的依赖库头文件要整理到该目录下的 include 子目录、.lib 放到 lib 子目录。PODOFO_BUILD_SHARED=OFF决定产出静态库而非 DLL；PODOFO_BUILD_LIB_ONLY=ON跳过 tools 目录下的示例和工具程序，少一大半编译错误源。

PODOFO_USE_FREETYPE=OFF和PODOFO_USE_OPENSSL=OFF是最关键的两个开关，它们直接决定 CMake 要不要去找 freetype 和 openssl 的头文件。保持 ON 又没装依赖，配置阶段就会红字报错；装了版本不对，编译阶段一样会死。我强调的「只留三个依赖」策略下，这两个必须显式写 OFF，不要依赖默认值。如果你手上的 0.9.7 源码里选项名略有差异，用 CMake GUI 勾选同名项即可，意思一样。

3.2 打开 .sln 后必改的四个工程配置

CMake 生成完，用 VS2005 打开 build_vs2005\podofo.sln。这时候先别急着 F7，按下面四项过一遍，否则编出来的库不是你想要的。

第一，字符集。项目属性 -> 常规 -> 字符集，从「使用 Unicode 字符集」改成「使用多字节字符集」。podofo 0.9.x 对外的接口几乎全部是 const char*（UTF-8 编码），VC8 下走的是窄字符分支。保持 Unicode 的话链接不报错，但运行时会看到 PDF 文本乱码或生成文件异常，属于「编译能过、跑起来才炸」的坑，最难排查。

第二，运行时库。项目属性 -> C/C++ -> 代码生成 -> 运行时库，Debug 全部设 /MDd，Release 全部设 /MD。podofo 自身的 CMake 默认按 /MD 编，如果你后面链接时把某个依赖库编成了 /MT，链接器会拿 LNK2038 反复砸你。统一运行时库是这一整条编译链的共识，谁不一致谁背锅。

第三，警告级别。把警告级别从 /W4 降成 /W3，并在预处理器定义里加 _CRT_SECURE_NO_WARNINGS。VC8 对 C 标准库的安全警告出了名的啰嗦，strcpy、sprintf 全都警告，podofo 源码里这类调用很多，不关掉的话编译输出窗口会有上千行警告，真正的错误会被淹没在刷屏里。

第四，输出目录。把所有项目的输出目录统一为$(SolutionDir)..\_bin\$(ConfigurationName)，中间目录也统一。否则 podofo 和 pocore 各输出各的，链接时你要去两个地方找 .lib，纯属给自己添堵。改完这四项再编译，能省下后面至少一半的排查时间。

3.3 源码级小补丁：VC8 缺失头文件的兜底

严格按 2.3 的版本锁依赖，podofo 源码本身基本不需要改。但实际编译时，某些老版本依赖库的公共头文件会间接引用 stdint.h，比如 libpng 在特定配置宏打开时会 include 它。这时最省事的做法不是去改库，而是给 VC8 补一个假的 stdint.h。

// 文件命名必须为 stdint.h，放到附加包含目录最前面 #ifndef FAKE_STDINT_H_ #define FAKE_STDINT_H_ typedef signed char int8_t; typedef short int16_t; typedef int int32_t; typedef __int64 int64_t; typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned __int64 uint64_t; typedef unsigned char uint_fast8_t; typedef unsigned int uint_fast16_t; typedef unsigned int uint_fast32_t; typedef unsigned __int64 uint_fast64_t; #define INT32_MIN (-2147483647 - 1) #define INT32_MAX 2147483647 #define UINT32_MAX 4294967295U #endif

逻辑说明：VC8 的 CRT 里没有 stdint.h，这个补丁用 VC 原生类型把最常见的定宽整型 typedef 出来，覆盖 8/16/32/64 位以及 fast 系列。把文件命名为 stdint.h，放到 VS2005 安装目录的 VC\include 下，或者放到你自己的附加包含目录最前面，编译时它就会优先生效。

参数说明：如果代码里还用到 intptr_t、uintptr_t 这类指针相关类型，可以再加两行 typedef，但编译 podofo 0.9.7 时通常用不到。补丁文件放好后再编译，C1083 找不到 stdint.h 的报错会彻底消失。这个补丁也适用于你手头其他老 VS 工程，一劳永逸，顺手留一份在自己的公共代码仓库里。

4. 依赖库预编译：zlib、libjpeg、libpng 在 VC8 下的完整过一遍

4.1 zlib：一分钟编完的硬依赖

zlib 是我见过对老编译器最友好的开源库。以 1.2.11 为例，解压后进入 zlib 源码目录，打开「Visual Studio 2005 命令提示」环境（开始菜单 -> Visual Studio 2005 -> Visual Studio Tools，确保 cl.exe 和 nmake.exe 在 PATH 里），执行：

cd D:\build\deps\zlib-1.2.11 nmake -f win32/Makefile.msc

逻辑说明：Makefile.msc 是 zlib 官方为 Windows 命令行编译准备的文件，nmake 会根据它依次编译出 zlib.lib（静态库）、zdll.lib（动态库导入库）和 zlib1.dll（动态库本体）。我们只需要静态路径，所以 zlib.lib 就是最终要的产物。

参数说明：zlib 编译几乎不会有错，唯一的注意事项是别用普通 cmd 窗口跑，否则 cl.exe 找不到，nmake 会报 U1077 或者干脆提示找不到命令。编译完成后，把 zlib.h、zconf.h 复制到 D:\build\deps\include，把 zlib.lib 复制到 D:\build\deps\lib，后续 CMake 的 CMAKE_PREFIX_PATH 就是靠这个目录结构找到它的。顺手用 dumpbin /headers zlib.lib 看一眼机器类型，确认是 x86 而不是 x64，老 VS2005 编不出 x64 库，如果你在 64 位机器上不小心用了别的工具链，这一步能提前暴露问题。

4.2 libjpeg：jconfig.vc 一处复制，剩下全是默认

libjpeg 在 VS2005 下编译同样简单。以 9b 版本为准，还是在 Visual Studio 2005 命令提示里：

cd D:\build\deps\jpeg-9b copy jconfig.vc jconfig.h nmake -f makefile.vc

逻辑说明：libjpeg 源码里默认没有 jconfig.h，而是根据不同平台提供 jconfig.vc、jconfig.bat 等模板。VS 环境下复制 jconfig.vc 为 jconfig.h，makefile.vc 编译时就会用这个配置。编译完生成 jpeg.lib 和 jpeg.dll（makefile.vc 里默认开了 DLL 选项），我们要的是 jpeg.lib。

参数说明：如果后面链接 podofo 时报找不到 jpeglib.h 或 jconfig.h，记得把 jpeglib.h、jconfig.h、jmorecfg.h 三个头文件一起复制到 D:\build\deps\include。只复制 jpeglib.h 不复制 jconfig.h 是新手最容易漏的，jconfig.h 里定义了 JPEG 库的编译期常量，缺失会让 jpeglib.h 里一堆 typedef 无法解析，报错看起来像语法错误，实际是配置头文件没到位。

4.3 libpng：老版本也要改两行路径

libpng 是三个依赖里最容易出岔子的，好在 1.2.59 给了 scripts\makefile.vc32 这个老牌编译脚本。做法是：

cd D:\build\deps\libpng-1.2.59 copy scripts\makefile.vc32 makefile.vc

然后编辑 makefile.vc，把文件顶部的 ZLIB_INCLUDE_DIR 和 ZLIB_LIB_DIR 两个变量指到 zlib 的源码目录和 zlib.lib 所在目录，保存后执行：

nmake -f makefile.vc

逻辑说明：libpng 1.2 的 makefile.vc32 本身不自动探测 zlib 的位置，两个路径变量必须手工指定。它编译时会把 png.h、pngconf.h 和 libpng.lib 输出到当前目录或 scripts 目录，具体看 makefile 里的定义。我们需要的产物是 libpng.lib 和头文件。

参数说明：路径变量里用反斜杠还是正斜杠都行，但目录名不要带空格，VS2005 的 nmake 对带空格路径处理得很差。如果你在后续 podofo 编译中看到 pngconf.h 的 C2146 语法错误，多半是 zlib 路径没对、PNG_ZLIB_VERNUM 之类的宏定义找不到，回去检查 ZLIB_INCLUDE_DIR 有没有指到真正的 zlib 源码头文件目录，而不是 zlib 的安装根目录。

三个依赖库编完后，D:\build\deps 下的结构应该是：

D:\build\deps\ include\ zlib.h zconf.h png.h pngconf.h jpeglib.h jconfig.h jmorecfg.h lib\ zlib.lib libpng.lib jpeg.lib

整理完这层目录，再回到第 3 章的 CMake 配置阶段，CMAKE_PREFIX_PATH 就能一次性把三个依赖全部找到，配置过程零红字。补充一句：VS2005 默认只支持 32 位目标，如果宿主系统是 64 位，你编出来的也是 32 位库，对老 MFC 系统这反而是对的，不用刻意追 x64。

5. VS2005 编译 podofo 的常见问题排查：5 个坑与对应解法

5.1 C1083 找不到 stdint.h，VS2005 天生缺这个文件

现象：编译 libpng 或 podofo 某些头文件时，报 fatal error C1083: Cannot open include file: 'stdint.h'。

原因：stdint.h 从 VS2010 起才随 CRT 提供，VS2005 的 include 目录里根本没有。2010 年之后的开源库普遍假设它是环境标配，导致老编译器集体翻车。

解决：给 VC8 补一个假 stdint.h（见 3.3 的代码块），放到 VC\include 目录或附加包含目录最前面。补了之后不仅 podofo 能编，手头其他老工程遇到同类问题也一并解决。如果不想用假头文件，就把依赖库退回到本笔记推荐的版本，libpng 1.2.59 和 zlib 1.2.11 都不需要它。我一开始也纠结造假头文件会不会埋雷，后来发现 VC8 的 CRT 里本来就没有这些类型定义，补上只是把标准补齐，风险极低。

5.2 LNK2038 运行时库不匹配，链接器直接罢工

现象：链接阶段报LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'。

原因：podofo 的 CMake 默认按 /MD 编译，而你手动编 zlib 或 libjpeg 时用了 /MT，或者反过来。静态库之间只要运行时库不一致，链接器就会拿这个宏定义较真，因为混用会在运行时造成堆被两个 CRTL 管理，崩溃是必然的。

解决：打开 VS2005 的项目属性，把 podofo、pocore、以及你自己消耗方工程的运行时库全部统一。Debug 用 /MDd，Release 用 /MD，一行都不许漏。依赖库那侧如果在 nmake 时没法直接改，就在它的 makefile 里搜 CFLAGS，把 /MT 改成 /MD 重新编一次。这个坑的隐蔽之处在于它不会在编译期暴露，要到链接最后一步才炸，而且报错信息里全是下划线宏名，新手很容易误判成代码问题。

5.3 C2664 字符集转换报错，Unicode 工程别直接传字符串

现象：在自己工程里调用 podofo API，凡是传字符串参数的调用都报C2664: cannot convert parameter from 'const char *' to 'LPCWSTR'，或者反过来。

原因：podofo 0.9.x 的对外接口固定用 const char*（UTF-8），它内部根本不做 ANSI 到 Unicode 的自动适配。你的工程如果设成了 Unicode 字符集，字符串字面量会被编译器解释成宽字符，两边类型对不上。

解决：podofo 工程本身在 3.2 里已经改成多字节字符集。调用方工程如果因为历史原因必须保持 Unicode，就在调用边界用 WideCharToMultiByte 转一下，或者写个小工具函数把 CString 转成 UTF-8 的 std::string 再传进去。这个坑属于编译能过、链接能过、运行时数据全错的隐性杀手，务必在联调前就处理掉。我见过有人传字符串进 PDF 生产者，跑出来全是问号，查了半天才发现是字符集问题。

5.4 头文件路径层级不对，png.h 明明在却找不到

现象：编译 podofo 时报 fatal error C1083: Cannot open include file: 'png.h'，打开资源管理器看，png.h 明明就躺在 D:\build\deps\include 下。

原因：附加包含目录只加到了 include 的上级目录，或者 podofo 源码里写的是#include <libpng/png.h>这种带前缀的引用（部分版本为了区分命名空间会这么写），而目录结构里没有 libpng 这一层。

解决：两个办法任选。一是把附加包含目录精确加到 D:\build\deps\include；二是如果报错路径带前缀，就在 include 下建一个 libpng 子目录，把 png.h、pngconf.h 放进去。我的习惯是统一用第一种，并把 zlib、jpeg、png 的头文件全部平铺在同一个 include 目录下，省得每个库建一层，也让 CMake 的 find_package 少一些搜索歧义。

5.5 链接工具程序报一堆 LNK2019，纯粹是自找的

现象：编译 podofo 时没关 tools，结果链接 podofoimg2pdf、podofotxtextract 这些工具时，报一堆 LNK2019: unresolved external symbol，而且符号都是 freetype 或 openssl 里的。

原因：这些工具默认链接了 freetype 和 openssl 的功能符号，你编译 podofo 时把两个依赖关了，但工具代码没跟着关干净。这不是 podofo 的 bug，是编译范围选大了。

解决：回到 CMake 命令，确认 PODOFO_BUILD_LIB_ONLY=ON 已经传进去。这个开关会把 tools、examples 全部排除，只生成 podofo 和 pocore 两个库目标。如果你确实需要某个工具，就得把 freetype 和 openssl 也编出来，那是另一套工作量，本笔记的路线不需要。很多人第一次编译时图省事不传这个参数，结果被工具链的链接错误误导，以为 podofo 库本身有问题，浪费大量时间。

6. 验证与嵌入：从 out.pdf 到 MFC 工程里的调用

6.1 用最小程序验证 lib 可用

依赖库和 podofo 都编完后，先写一个 20 行的最小程序验证，确认静态库不是空壳。新建一个控制台工程，把 podofo 源码的 src 目录和 4.3 整理的 D:\build\deps\include 加进附加包含目录，链接时按顺序加 podofo.lib、pocore.lib、libpng.lib、jpeg.lib、zlib.lib。代码就写最简单的一件事：创建一个空白 PDF 并保存。

#include <podofo/podofo.h> using namespace PoDoFo; int main() { PdfMemDocument doc; PdfPage* page = doc.GetPages().CreatePage( PdfPage::CreateStandardPageSize(PdfPageSize::A4)); if (!page) { return -1; } doc.Save("out.pdf"); return 0; }

逻辑说明：PdfMemDocument 是内存型 PDF 文档，CreateStandardPageSize 按 A4 纸张尺寸建页，GetPages().CreatePage 把这个页挂到文档的页面树里，最后 Save 落盘。如果这 20 行能跑通并生成 out.pdf，说明 podofo 与 pocore 之间的符号依赖全部解析成功，也说明三个依赖库的链接顺序正确。链接顺序在 VS2005 的链接器里是从左到右解析符号的，podofo.lib 必须放在 pocore.lib 前面，否则会出现找不到符号的假象。

参数说明：如果页面创建失败，优先检查页面的资源字典是否被意外修改；更常见的是库没编对——用系统记事本打开 out.pdf，文件头必须是 %PDF-1.x，如果看到 0 字节文件，回去检查 3.2 的运行时库配置。等你看到 PDF 阅读器能正常打开这个空白页，库的可用性就实锤了。

6.2 嵌入 MFC 工程的两个习惯

验证完，把 podofo 的头文件和 lib 收进你自己的 deps 目录，别再把绝对路径写死在 .vcproj 里——VS2005 的工程文件在多人机器上换一次路径就全线飘红，相对路径是唯一的后悔药。调用时注意：持有 PdfMemDocument 对象的类，析构函数里要先调用 doc.Clear() 再释放关联对象，podofo 0.9.x 的析构顺序有时候会触发断言，这是我实际排查过的问题。另外老工程如果定义了 _AFXDLL，要确认 podofo 库本身不是用 /MDd 和 MFC 静态库混编的，否则链接期会报一堆关于 _AFX 符号的冲突。

我个人的习惯是：所有老工程依赖的开源库，版本一旦跑通就写死在库清单里，绝不随手升级。第一次编 podofo 时，我就是因为顺手拿了最新版 libpng，被 stdint.h 和一堆 C2146 折腾了两天，最后锁回 1.2.59，半小时全通。希望这篇笔记能帮你在 VS2005 上少走这些弯路，一次编出能用的 podofo 0.9.7 库。

本文还有配套的精品资源，点击获取