Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1522314
  • 博文数量: 114
  • 博客积分: 10010
  • 博客等级: 上将
  • 技术积分: 1357
  • 用 户 组: 普通用户
  • 注册时间: 2006-11-19 18:13
文章分类
文章存档

2010年(8)

2009年(9)

2008年(27)

2007年(62)

2006年(8)

我的朋友

分类: C/C++

2007-06-22 16:03:21

移植linux下面的x264编码器到win32平台的时候,有很多需要注意的地方,在这里,我只写写我遇到和解决了的问题。
 
(1)asm问题
这个需要下载nasm汇编工具,在偶的博客上已经上传了。可以博客上的文章:
“参考接上篇xvid-core1.1.2编译方法(vc6,vs2005)”
需要将nasm.exe拷贝到D:\Program Files\Microsoft Visual Studio 8\VC\bin,具体的编译选项的修改,可以参考这篇文章。
 
(2).c文件编译问题
首先去掉“预编译头”,设置为“不使用预编译头”,虽然不使用预编译头会导致编译速度变慢,但是可以避免很多莫名其妙的问题。
 
然后不要忘记在当前项目的“属性”里面设置“c/c++”的“预处理器”设置,预处理器定义为:WIN32;_WINDOWS;_DEBUG;__X264__;HAVE_MMXEXT;HAVE_STDINT_H;HAVE_SSE2;ARCH_X86
 
最后在vs2003的“解决方案管理器”里面右键单击每一个.c文件,然后选择“属性”,然后“c\c++”,然后选择“高级”,然后在“编译为”属性中设置成“编译为c++代码(/TP)”,基本上就可以了。
 
有的纯c语言的头文件没有加extern "C",可以添加如下代码:
#ifdef __cplusplus
extern "C" {
#endif
// 常规的c函数定义
void foo(int x, int y) ;
...
#ifdef __cplusplus
}
#endif
 
到了这一步,基本上编写的质量高的代码,或者不依赖于linux系统库的代码应该可以直接编译运行了。
 
(3)x264当中的getopt_long函数问题
这个函数让人非常难以理解,它不断的蹦出如下错误:
error C2664: 'getopt_long' : cannot convert parameter 1 from 'int' to 'int
*(__cdecl *)(void)'
好好的代码,extern "C"也加了还是出这种问题,一怒之下刨根问底之!
原来在:c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdlib.h
文件中含有如下代码:
#if defined(_DLL) && defined(_M_IX86)
#define __argc (*__p___argc()) /* count of cmd line args */
#define __argv (*__p___argv()) /* pointer to table of cmd line args */
#define __wargv (*__p___wargv()) /* pointer to table of wide cmd line args
*/
#define _environ (*__p__environ()) /* pointer to environment table */
#else
这里面已经定义了__argc, __argv这些变量,而x264的extra目录下面的GetOpt.h文件中的getopt_long函数定义就是使用了这个双下划线的argc和argv,难怪编译不过去啊。
呵呵,解决方法很简单,删掉一个下划线即可。
 
(4)pow的重复问题
往后的编译就是一些毛毛雨问题了,后来还是蹦出来如下错误:
 error C2666: 'pow' : 7 overloads have similar conversions
        C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(620): could be 'long double pow(long double,int)'
        C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(618): or       'long double pow(long double,long dou
ble)'...等等不在赘述。
后来一查,原来vs2003的math.h里面定义了7个pow计算次方的函数,x264的开发者对于这个pow函数调用没有那么严谨,没有严格指定每个pow的形参的数据类型,这就导致了这个错误。
解决方法很简单,自己强制转换一下调用处的pow参数类型,就可以解决。
例如:
    rc->lstep = (double)pow( (double)(2.0), (double)(h->param.rc.i_qp_step) / (double)(6.0)) ;
这样,明确的标明形参的类型,这个傻傻的vs2003编译器就可以知道了。
 
别的似乎就没有什么问题了,只是注意不要在.c文件中使用c++的一些流什么和stdnamespace之类的就可以了。发一张成功后的图庆祝一下 :)
阅读(3800) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~