首页 > 代码库 > error: stray '\377' in program

error: stray '\377' in program

cygwin编译报错:**.cpp:1:1: error: stray ‘\377‘ in program解决方法

 2061人阅读 评论(1) 收藏 举报




编译报错内容:

[armeabi] Compile++ thumb: cocos2dcpp_shared <= HelloWorldScene.cpp

jni/../../Classes/HelloWorldScene.cpp:1:1: error: stray ‘\377‘ in program
jni/../../Classes/HelloWorldScene.cpp:1:1: error: stray ‘\376‘ in program
jni/../../Classes/HelloWorldScene.cpp:1:1: error: stray ‘#‘ in program
jni/../../Classes/HelloWorldScene.cpp:1:4: warning: null character(s) ignored [enabled by default]

jni/../../Classes/HelloWorldScene.cpp:1:6: warning: null character(s) ignored [enabled by default]

……

jni/../../Classes/HelloWorldScene.cpp:49:2: error: expected unqualified-id before ‘/‘ token
/cygdrive/e/cocos2d/Android-ndk-r9c-windows-x86/android-ndk-r9c/build/core/build-binary.mk:388: recipe for target ‘obj/local/armeabi/objs/cocos2dcpp_shared/__/__/Classes/HelloWorldScene.o‘ failed
make: *** [obj/local/armeabi/objs/cocos2dcpp_shared/__/__/Classes/HelloWorldScene.o] Error 1
make: Leaving directory ‘/cygdrive/e/cocos2d/cocos2d-x-2.2.1/projects/GODS/proj.android‘


在网上找了好几下,没能解决。

有的人说:可能是因为格式不是纯粹的TXT格式子,而我用的编辑器没能认出来。

也有的人说:这个错误一般是源代码中含有一些隐藏的非ascii字符,可能原因在编辑器中使用的utf-8的格式保存源代码中出现了中文的标点符号。

他们建议把东西copy到文本编辑器中,再copy回来试试

还有网友的建议是用UE(下载地址:http://lwr0312.blog.163.com/blog/static/48336807200931695730586/edit/)打开,用16进制编辑,删除掉最前面多余的字节。

我对着操作,搞得晕乎乎,呜呜……没有多余的字或者中文符号啊!并没有解决问题。

后来终于看到一个帖子,里面的“gcc”几个字,让我看到了希望!!!下面附上地址:

http://wenku.baidu.com/link?url=_NgJPYtTUJ-WwLFEk38GgS_e5YdjYlltuc9E4oc4wvGHeGgk7OopTKzX66Epfg6MEYR1M7npZBnNkkwxwG7oRkZpxPgCIoVF6pTNYOYJ7YS

文中提及到“这是因为你的编译器将文件编码存为了UTF-8格式的,可是winavr作为gcc的编译器是不认识这种格式的”,“将UTF-8改掉,改成US-ASIIC或者Chinese Simple(GB2312)都行,为什么Chinese Simple(GB2312)也行我也不知道,可能其他的也行只要不是UTF-8就行了”。

我这个原本是mac上的项目,移植到win的vs中时我把格式存为Unicode(当时错了!如果当时就改为了ANSI就不会有这些报错了!),现在从VS弄到安卓中(通过cygwin的gcc)要把格式另存为ANSI,然后就可以编译通过了。

搞定,收工!终于,可以安心睡觉觉了!晚安,good night


不能手工 不能啊  这是别人的错误

ttps://loki-lib.svn.sourceforge.net/svnroot/loki-lib/trunk
把代码检出到本地,执行 make 后提示错误:
../../include/loki/StrongPtr.h:1: error: stray ‘/357’ in program
../../include/loki/StrongPtr.h:1: error: stray ‘/273’ in program
../../include/loki/StrongPtr.h:1: error: stray ‘/277’ in program
根据错误提示,应该是文件里存在非 ASCII 码的字符,用 file 命令查看了一下 StrongPtr.h 的类型,发现是 Unicode text, UTF-8,而别的源文件则是 ASCII C++ program text,看来是 Loki 的某个维护者不小心把源文件存成 UTF-8 编码的文件并在里面引入了非 ASCII 字符(UTF-8 编码是一种兼容 ASCII 编码的变长编码方案)。上述的编译错误中的字符是以 8 进制表示的,将其转换成 16 进制后发现是”EF BB BF”,看着很眼熟——好像是 BOM(byte order mark) 控制字符,去维基百科里查一下 BOM 词条,发现 UTF-8 文件的 BOM 果真是”EF BB BF”。而大多数 Windows 文件编辑器(包括记事本)在将文件保存为 Unicode 编码时默认都会悄悄的在文件头加上 BOM 字符且不会将其显示出来(用 WinHex 之类的十六进制编辑器就打开则可以看到 BOM 字符),而 Linux 下却没这个默认的规矩,所以 Linux 下 g++ 不认 BOM 也是情理之中的。看来是 Loki 的维护者在 Windows 下修改代码后不小心将 StrongPtr.h 存成 UTF-8 编码文件,引入了肉眼看不到的 BOM 字符。后将 StrongPtr.h 另存为 ASCII 编码的文件后果然编译通过。
找到问题后去 Loki 的开发论坛上报告了这一问题,维护者之一的 syntheticpp 随后修正了问题并在回帖里打趣的说:
Good to know “no BOMbs on Linux” ;-)
一语双关的将 BOM 字符比作 BOMB(炸弹),呵呵,隐匿在文件里的 BOM 看不到摸不着,编译时报告的错误也很不直白,大家在使用 Windows 下的文本编辑器编写跨平台代码时要注意这个问题,建议使用 Notepad++ 这种可以显式指定是否要加 BOM 字符的编辑器,以免挨炸。

  • 0





error: stray '\377' in program