Ogg vorbis坠机

Question

我试图在我的项目中添加对Ogg的支持(C++，VS 2010)。我在编译LibOgg + LibVorbis以生成一个静态库时没有问题。

我的程序是：

LibOgg

• 下载LibOgg
• 使用动态解决方案构建LibOgg (发行版)
• 在libogg.lib文件夹中获取一个libogg.dll导出和一个libogg.dll

LibVorbis

• 下载LibVorbis
• 为LibOgg设置适当的包含+库文件夹
• 使用动态解决方案构建LibVorbis (发行版)
• 获取libvorbis.lib和libvorbisfile.lib导出以及/Release文件夹中的libvorbis.dll和libvorbisfile.dll

我的程序

• 为Libogg + LibVorbis .lib导出设置适当的包含+库文件夹
• 将.dll放在工作目录中

构建成功，但与静态构建不同(静态构建有效)，动态构建只是在第一个ov_open调用中崩溃(该调用打开一些.ogg文件)。我建了很多图书馆(GLEW，SQlite等)但这次却让我大吃一惊。

Answer 1

没关系，我解决了这个问题。由于stdio.h和OggVorbis的一些链接问题，在Windows和ov_open的使用方面，似乎很敏感。

文档说得很清楚：

对Windows开发人员的警告:不要在Windows应用程序中使用ov_open()；Windows链接对成功传递文件*句柄设置限制，而ov_open()与这些限制发生冲突。有关使用ov_open_callbacks()的详细信息，请参阅ov_open_callbacks()页面。

虽然docs建议使用回调，但我发现ov_fopen是可靠的，它适用于OggVorbis的静态和动态构建；如果在Windows上使用ov_open，动态构建会使程序崩溃。

在我在Linux和OSX上测试这个答案之后，将更新这个答案，以验证ov_fopen是一个安全的、全方位的解决方案。

更新

如前所述，我在Windows7、Lubuntu、OSX (10.8.2)和Android4.4.4上测试了ov_fopen的使用情况，并发现这是可靠的。因此，对于那些对回调过敏的人(比如我)，ov_fopen被证明是可靠的。